进行TDD时中大型应用程序的设计? [英] design of mid-large sized application when doing TDD?

问题描述

我很好地掌握了单元测试、DI、模拟以及尽可能接近完整代码覆盖率所需的所有设计原则优点(单一责任原则，在我编写代码时思考我将如何测试"，等等...)

I have a good grasp of unit testing, DI, mocks, and all the design principal goodness required to have as close to full code coverage as humanly possible (single responsibility principal, think 'how will i test this' as I code, etc...).

我最近的应用程序，我没有编写真正的 TDD.我在编写代码时牢记单元测试，并在编写代码、重构等之后编写了我的测试.我现在做...这是我充分利用 DI、模拟框架等的第一个项目，也是第一个具有完整代码覆盖率的项目 - 在我进行过程中我从中学到了很多东西.我很想被分配到我的下一个项目，这样我就可以完全从头开始编写 TDD.

My most recent app, I did not code doing true TDD. I kept unit-testing in mind as I coded, and wrote my tests after writing the code, refactoring, etc.. I did TDD when it was 'easy' to do... however I did not have as good of a grasp as I do now... That was the first project I made full use of DI, mocking frameworks, etc, and the first which had full code coverage - and I learned a lot from it as I went along. I'm itching to get assigned to my next project so I can code it completely doing TDD from scratch.

我知道这是一个广泛的问题，我已经通过示例和 XP Unleashed 订购了 TDD，但我希望简要概述你们如何设计/编写执行 TDD 的大型应用程序.

I know this is a broad question, and I've already ordered TDD by example and XP Unleashed, but I'm hoping for a brief overview of how you all design / write a large application doing TDD.

您是否仅使用残存代码编写整个应用程序?(例如，编写所有函数签名、接口、结构，并编写整个应用程序，但不编写任何实际实现)?我可以想象它适用于中小型应用程序，但这甚至可能适用于大型应用程序吗?

Do you write the entire application, using nothing but stubbed out code? (e.g., write all the function signatures, interfaces, structures, and write the entire application but without writing any actual implementation)? I could picture it working on small-mid sized, but is this even possible on large applications?

如果没有，您将如何为系统中的最高级别功能编写第一个单元测试?举个例子 - 在一个网络服务上，你有一个名为 DoSomethingComplicated(param1,...,param6) 的函数向世界公开.显然，首先为像 AddNumbers() 这样的简单函数编写测试是微不足道的——但是当该函数位于调用堆栈的顶部时，像这样?

If not, how the heck would you write your first unit test for the highest level function in your system? Lets say for example - on a web service where you have a function called DoSomethingComplicated(param1,...,param6) exposed to the world. Obviously, writing the test first for a simple function like AddNumbers() is trivial - but when the function is at the top of the call stack such as this?

您是否仍然进行前期设计?显然你仍然想做架构"设计——例如，一个流程图显示 IE 与 IIS 对话，后者通过 WCF 与 Windows 服务对话，后者与 SQL 数据库对话......显示所有 SQL 表及其字段的 ERD，等等...但是类设计呢?类之间的交互等?你是预先设计这个，还是只是继续编写存根代码，随着你的进行重构交互，直到整个事情连接起来并且看起来可以工作?

Do you still do design up-front? Obviously you still want to do 'architecture' design - e.g., a flow chart showing IE talking to IIS which talks to a windows service via WCF which talks to the SQL Database... an ERD which shows all your SQL tables and their fields, etc... but what about class design? Interactions between the classes, etc? Do you design this up-front, or just keep writing stub code, refactoring the interactions as you go along, until the whole thing connects and looks like it will work?

非常感谢任何建议

推荐答案

我是否编写了整个应用程序，只使用被删减的代码?

不，绝对不是 - 这听起来是一种非常浪费的方法.我们必须始终牢记，进行 TDD 的根本原因是快速反馈.自动化测试套件可以告诉我们是否比手动测试更快地破坏了任何东西.如果我们等到最后一刻才将事情连接在一起，我们将无法获得快速反馈——虽然我们可能会从单元测试中获得快速反馈，但我们不知道应用程序是否可以作为一个整体运行.单元测试只是我们需要执行的一种测试形式来验证应用程序.

No, not in the slightest sense - that sounds like a very wasteful approach. We must always keep in mind that the underlying reason for doing TDD is rapid feedback. An automated test suite can tell us if we broke anything much faster than a manual test can. If we wait wiring things together until the last moment, we don't get rapid feedback - while we may get rapid feedback from our unit tests, we wouldn't know if the application works as a whole. Unit tests are only one form of test we need to perform to verify the application.

更好的方法是从最重要的功能开始，然后使用由外而内的方法从那里开始.这通常意味着从一些用户界面开始.

A better approach is to start with the most important feature and work your way in from there, using an outside-in approach. This often means starting with some UI.

我的做法是创建所需的用户界面.由于我们通常无法使用 TDD 开发 UI，因此我只是使用选择的技术创建视图.那里没有测试，但我将 UI 连接到一些 API(最好使用声明性数据绑定)，然后测试就开始了.

The way I do it is by creating the desired UI. Since we normally can't develop UI with TDD, I simply create the View with the technology of choice. No tests there, but I wire up the UI to some API (preferrably using declarative databinding), and that's when the testing begins.

一开始，我会 TDD 我的 ViewModels/Presentation Models 和相应的 Controllers，可能对一些响应进行硬编码以查看 UI 是否有效.只要我有一些在你运行时不会爆炸的东西，我就会签入代码(记住，很多小的增量签入).

In the beginning, I would then TDD my ViewModels/Presentation Models and corresponding Controllers, possibly hard-coding some responses to see that the UI works. As soon as I have something that doesn't explode when you run it, I check in the code (remember, many small incremental check-ins).

我随后会垂直沿该功能进行工作，并确保此特定 UI 可以一直到达数据源(或其他任何内容)，而忽略所有其他功能.

I subsequently work my way vertically down that feature and ensure that this particular piece of UI can go all the way to the data source (or whatever), ignoring all other features.

功能完成后，我可以开始下一个功能.我想象这个过程的方式是，我通过一次做一个垂直切片来填写应用程序，直到完成所有功能.

When the feature is done, I can start on the next feature. The way I picture this process is that I fill out the application by doing one vertical slice at a time until all features are done.

以这种方式启动一个全新的应用程序总是需要额外的很长时间来开发第一个功能，因为这是你必须连接所有东西的地方，所以选择一些简单的东西(比如应用程序的初始视图) 使事情尽可能简单.完成第一个功能后，接下来的功能就会变得容易得多，因为基础现已就绪.

Kick-starting a greenfield app this way always takes extra long time for the first feature since this is where you have to wire up everything, so pick something simple (like the initial View of the app) to keep things as simple as possible. Once the first feature is done, the next ones become much easier because the foundations are now in place.

我还需要预先设计吗?

不多，没有.在开始之前，我通常会有一个整体设计，当我在团队中工作时，我们会在开始之前在白板或幻灯片上勾勒出整体架构.

Not much, no. I normally have an overall design in mind before I start, and when I work in a team, we sketch this overall architecture on a whiteboard or a slide deck before we start.

这或多或少限于

• 层的数量和名称(UI、表示逻辑、领域模型、数据访问等).
• 使用的技术(WPF、ASP.NET MVC、SQL Server、.NET 3.5 或其他)
• 我们如何构建生产代码和测试代码，以及我们使用哪些测试技术
• 代码质量要求(结对编程、静态代码分析、编码标准等)

其余的我们会边走边想，但随着我们的进行，我们会在白板上使用许多临时设计会议.

The rest we figure out as we go, but we use many ad-hoc design sessions at the whiteboard as we go along.

这篇关于进行TDD时中大型应用程序的设计?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！