从头开始一个 TDD 项目 [英] Starting a TDD project from scratch

问题描述

我阅读了很多关于 TDD 和单元测试的问答，但我没有找到答案:我从哪里开始?

I read a lot of question and answer on TDD and unit testing on SO but I found nothing that answer to that: where do I start from?

我和团队已经完成了几个项目，其中我们采用了单元测试，用于我们的代码......但是首先编写代码，然后进行单元测试.在开发过程的某个阶段，先编写测试然后编写代码变得很自然，这使我们采用了更 TDD 的风格.

Me and team already done a couple of project in which we adopted the use of unit testing, for our code... but code first and then unit testing. At some point of the development process, it became quite natural to write the test first and then the code, bringing us to a more TDD style.

现在我们要进行下一步，尝试从头开始使用 TDD 开始一个新项目.问题来了……从哪里开始?当我完全没有代码时，我会写的第一个测试是什么?

Now we would like to make the next step and try to start a new project with TDD from the beginning. Here's the problem... where to start from? Which is the first test I'd write when I have no code at all?

让我们说，只是为了有一个考虑的上下文，我必须开发一个互联网应用程序，以文档为中心，有一些工作流程和......别的东西.但是让我们从头开始:首先，我想创建一个简单的页面，列出存储在数据库表中的所有文档(元数据)(很简单，嗯?).我要写的第一个测试是哪个?假设我正在使用 Hibernate 访问数据库...我会测试假设的方法 getAllDocuments() 吗?但是我应该使用模拟对象来代替 Hibernate 吗?那么我在测试什么?

Let's say, just to have a context to think about, that I have to develop an internet application, document-centric, with a little work flow and... something else. But let's start from the beginning: first thing, I want to create a simple page that list all the document (metadata) stored in a table on a DB (quite simple, uh?). Which is the first test I'd write? Let's say that I'm using Hibernate to access the db... would I test the ipothetical method getAllDocuments()? But should I use a mock object to substitute Hibernate? So what am I testing?

我在这里有点困惑……而且 getAlDocuments() 可能永远不会成为一种生产方法……所有文档集合都将被某种东西排序和过滤……这有意义吗?任何建议将不胜感激

I'm a little confuse here... moreover the getAlDocuments() probably will never be a production method... all the collection of documents will be ordered and filtered by something... does it make sense? Any suggestion will be appreciated

已

阅读您的答案(以及 http://programmers.stackexchange.com 上的类似帖子)后，我对TDD，但我还有一个疑问.

After reading your answers (and the similar thread at http://programmers.stackexchange.com) I come with a better vision of TDD, but I still have a dubt.

我一直认为 TDD 是首先进行单元测试...从未想过端到端测试.但是让我问一下:TDD 说你必须写一个测试并看到一个编译错误；然后创建类和方法，然后测试失败；然后您实现该方法并通过测试.在测试失败之前，您无法编写代码；在所有测试通过之前，您无法编写另一个测试.我在吗?

I always though TDD is about making unit test first... never thought about end-to-end test. But let me ask: TDD say you have to write a test and see a compilation error; then you create class and method and you get a test failure; then you implement the method and get the test passed. You cannot write code until there's a test that fail; you cannot write another test until all test pass. Am I right here?

如何将端到端测试作为我的第一次测试?我应该在所有层中编写所有代码，以使该测试通过.但随后我将有一堆类和方法都通过我的端到端测试进行测试(尽管我不应该称其为集成测试吗?).这意味着我不再需要单元测试，因为我已经有一个涵盖我的代码的测试.而且我不能写一个已经通过的测试，这违反了 TDD 实践.

How can I make an end-to-end test as my first test? I should write all the code, in all the layer, to let that test passed. But then I'll have a bunch of classes and methods all tested by my end-to-end test (shouldn't I call it integration test though?). This means I won't need unit test anymore, because I already have a test that cover my code. And I can't write a test that pass already, it's against TDD pratice.

请帮助我理解这更进一步的步骤

Help me understand this further step ahead please

推荐答案

TDD 与单元测试无关 - TDD 是关于通过测试推动您的开发和架构 - 使用您需要的任何类型的自动化测试.你明白重点了吗?

TDD is not about unit testing - TDD is about driving your development and architecture with tests - with any type of automated tests you need. Do you see the point?

您正在开始一个新项目，并且您可能拥有一组功能.对于将要实现的功能，您应该有一些验收标准.这些标准可以定义您的顶级测试.让我们从端到端测试(有时这可能非常困难，因为它涉及尚不存在的 UI)或针对这些验收标准的集成测试开始.一旦您的测试失败，您将继续实现与大型测试相关的功能，但每个此功能将再次通过集成或单元测试驱动.如果所有顶级测试都通过，则该功能完成.

You are starting a new project and you probably have a set of features. You should have some acceptance criteria for features you are going to implement. These criteria can define your top level tests. Let's start either with an end-to-end test (this can be quite hard sometimes because it involves UI which doesn't exist yet) or integration test for these acceptance criteria. Once you have test which is failing you will continue to implement features related to the large test but each this feature will be again driven either with an integration or an unit test. The feature is completed if all top level tests pass.

如果您跳过大型测试(端到端、集成)，您将开发一组经过良好测试的单元，这些单元在集成在一起时将无法正常工作，或者您的架构由于单元测试定义的局部范围而不会很好.集成和端到端测试为您提供全球范围.

If you skip large tests (end-to-end, integration) you will develop set of well tested units which will either do not work when integrated together or your architecture will not be very good because of local scope defined by unit tests. Integration and end-to-end tests give you a global scope.

这在Growing Object-Oriented Software Guided by测试.

这篇关于从头开始一个 TDD 项目的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！