在代码中试验Cockburn用例

我正在编写一些复杂的UI代码。我决定将Cockburn用例用于鱼类，风筝和海平面(由Martin Fowler在他的著作《 UML Distilled》中讨论)。我将Cockburn用例包装在静态Cobject中，以便可以针对代表UI工作流程中步骤的静态常量测试逻辑条件。想法是我们可以阅读代码并知道它在做什么，因为包装的对象及其公共竞争者通过名称空间为我们提供了英语用例。

另外，我将使用反射来抽出包括所描述用例的错误消息。这个想法是，堆栈跟踪可能包含一些UI用例步骤(英语)……。事实证明，这是一种实现微型伪轻量级域语言的有趣方法，而无需编写DSL编译器。所以我的问题是，这是否是一个好方法？有没有人做过类似的事情？

cexample片段如下

假设我们有一个aspx页面，其中包含3个用户控件(包含许多可点击的内容)。用户必须单击一个特定用户控件中的内容(可能进行某种选择)，然后UI必须在视觉上提示用户选择成功。现在，在选择该项目的同时，用户必须浏览网格视图以在其他用户控件之一中找到一个项目，然后进行选择。这听起来很容易管理，但是代码可能很难看。

在我的情况下，用户控制所有发送的事件消息，这些消息被主页捕获。这样，页面就像UI事件的中央处理器一样，可以跟踪用户单击时发生的情况。

因此，在aspx主页中，我们捕获了第一个用户控件的事件。

using MyCompany.MyApp.Web.UseCases;   

protected void MyFirstUserControl_SomeUIWorkflowRequestCommingIn(object sender, EventArgs e)
{
  // some code here to respond and make "state" changes or whatever
  //
  // blah blah blah

  // finally we have this (how did we know to call fish level method?? because we knew when we wrote the code to send the event in the user control)
  UpdateUserInterfaceOnFishLevelUseCaseGoalSuccess(FishLevel.SomeNamedUIWorkflow.SelectedItemForPurchase)

}

protected void UpdateUserInterfaceOnFishLevelGoalSuccess(FishLevel.SomeNamedUIWorkflow  goal)
{
  switch (goal)
  {
     case FishLevel.SomeNamedUIWorkflow.NewMasterItemSelected:
           //call some UI related methods here including methods for the other user controls if necessary....
           break;
     case FishLevel.SomeNamedUIWorkFlow.DrillDownOnDetails:
           //call some UI related methods here including methods for the other user controls if necessary....
           break;
     case FishLevel.SomeNamedUIWorkFlow.CancelMultiSelect:
           //call some UI related methods here including methods for the other user controls if necessary....
           break;

     // more cases...

     }
  }

}

//also we have
protected void UpdateUserInterfaceOnSeaLevelGoalSuccess(SeaLevel.SomeNamedUIWorkflow  goal)
{
  switch (goal)
  {
     case SeaLevel.CheckOutWorkflow.ChangedCreditCard:
        // do stuff

     // more cases...

     }
  }

}

因此，在MyCompany.MyApp.Web.UseCases命名空间中，我们可能具有以下代码：

class SeaLevel...
class FishLevel...
class KiteLevel...

嵌入在类中的工作流程用例可以是内部类，静态方法或者枚举，也可以是给我们最清晰命名空间的内容。我不记得我最初做过的事，但你知道了。

解决方案

我认为这是"中介模式"与"设计模式"("四人帮")的不同-因此，我想说这是一种有效的方法。在模式中，他们讨论了控件之间复杂的交互是使用它的原因。

编辑：链接到Wikipedia上的Mediator

我从来没有做过，但是我经常想过要以UC风格编写代码，首先要有主要的成功路径，然后将扩展作为异常捕获在下面。还没有找到这样做的借口，希望看到有人尝试它并编写代码，即使在我们确定实验很糟糕之后，尝试并参考仍然会很有趣。