由于我是TDD新手,我目前正在开发一个小型C#控制台应用程序以便练习(因为练习很完美,对吧？).我首先简单地描述了如何组织应用程序(按类),并开始逐个开发我可以识别的所有域类(当然先测试).
最后,必须将类集成在一起以使应用程序可运行,即在Main方法中放置必要的代码,调用必要的逻辑.但是,我不知道如何以"先测试"的方式完成最后的整合步骤.
我想如果我使用"自上而下"的方法,我不会遇到这些问题.问题是:我该怎么做？我应该通过测试Main()方法开始吗？
如果有人能给我一些指示,我将非常感激.
Lun*_*ore 32
"自上而下" 已经在计算中用于描述分析技术.我建议改用术语"从外到内".
从BDD开始,从外部开始,我们认识到系统通常有多个用户界面.用户可以是其他系统以及人.BDD方法类似于TDD方法; 它可能对你有所帮助,所以我将简要介绍一下.
在BDD中,我们从一个场景开始 - 通常是使用该系统的用户的简单示例.周围的情景对话有助于我们制定出什么样的系统,应该真正做到.我们编写了一个用户界面,如果需要,我们可以针对该用户界面自动化场景.
当我们编写用户界面时,我们尽可能地保持它.用户界面将使用另一个类 - 控制器,视图模型等 - 我们可以为其定义API.
在此阶段,API将是空类或(程序)接口.现在我们可以编写用户界面如何使用此控制器的示例,并显示控制器如何提供价值.
这些示例还显示了控制器的职责范围,以及它如何将其职责委托给其他类,如存储库,服务等.我们可以使用模拟来表达该委托.然后我们编写该类以使示例(单元测试)起作用.我们编写了足够的示例来使我们的系统级场景通过.
我发现重写虚拟的例子是很常见的,因为模拟的接口最初只是猜测,然后在编写类时更充分地出现.这将有助于我们定义下一层接口或API,我们将为此描述更多示例,依此类推,直到不再需要模拟并且第一个场景通过为止.
当我们描述更多场景时,我们在类中创建不同的行为,并且我们可以重构以消除不同场景和用户界面需要类似行为的重复.
通过以外部方式执行此操作,我们可以获得尽可能多的API信息,并尽可能快地重新编写这些API.这符合Real Options的原则(除非你知道为什么,否则永远不要提早).我们不创建任何我们不使用的东西,API本身是为可用性而设计的 - 而不是为了便于编写.代码倾向于使用域语言而不是编程语言以更自然的方式编写,使其更具可读性.由于代码的读取速度比编写的大10倍,因此这也有助于使代码具有可维护性.
出于这个原因,我会使用从外到内的方法,而不是自下而上的智能猜测.我的经验是,它可以实现更简单,更强大的解耦,更易读和更易维护的代码.