The over-arching rule is: Do the riskiest items first.
Doing the test-cases first is, implicitly, arguing that the riskiest part of the coding is miscommunications and misunderstandings of the interfaces and behaviour of the objects that are being created.
For many projects, that may well be true, and TDD is very appropriate in those cases.
However, in many projects that is not the case, and applying TDD in those cases is a poor choice.
If your highest risk is usability, stop futzing about with unit tests and do some UI prototyping.
If your highest risk is performance, do some performance prototypes first, and don't worry about interfaces.
This list goes on.
Doing the risky items first has many advantages:
Projects that are inevitably doomed die early, before many resources are wasted.
Projects that are in trouble but are salvageable get the project management focus early, when it can do some good.
The business side of your organization will value a project higher when it has a low risk of failure; there's less chance that it will be cancelled early unnecessarily.
"I hear that it's often recommended to write tests and mock things before writing a single line of implementation.... I eventually go back and write unit tests... Is this different than what you're "supposed to do"?"
Since you started out with the answer to your own question, then you're not really asking that question are you?
There are lots of reasons why people answer their own questions. Sometimes, it's a way of arguing. It allows folks to say "I'm not arguing, I'm just asking why this is so wrong".
The goal is test first. Here's how it works.
Say I'm making a prototype and I'm not sure how everything is going to work yet.
I do, however, know one thing. What it's supposed to do.
Write down a concrete example of what it's supposed to do. Concrete, specific inputs and outputs.
That's the test case. I did it first. Can I formalize this as a unit test? Probably not. However, I started with an acceptance test case.
Now, I can break the problem into pieces.
So I just start finding examples of each step that I think I need.
For each example of something I think I need, I write down what goes in and what comes out from the step.
Those are test cases. I did them first. In many cases, I can formalize those as unit tests.
Once I have a test, I go back to the example of each step and throw it into my code.
I did testing, then coding. I didn't do ALL the testing before ANY of the coding. I did testing first, but not in a crazy all-test-no-code way. I did it in an incremental test-a-little-code-a-little way. But everything was test first.
This is simple, the answer is during prototyping. At this stage you don't understand the system your building well enough to test correctly, and anyways good practice says prototype code should be throw-away code so testing will not give you any real benefits at this stage. But the understanding gleamed from prototyping will help you so you can make effective testing once you enter production.
So yes your approach is correct, if you do test after prototypes
当您进行更多单元测试练习时，您可能会发现在测试中创建原型比创建控制台应用程序更快。 我的意思并不是说创建一个测试和一个单独的类，我的意思是在测试方法中探索代码。 我已经这样做过很多次了，而且我对此非常满意。 当我学习新的 api 甚至新语言时，测试为我尝试实验提供了最快的反馈周期。 然后，一旦代码正常工作，我就可以将其提取到一个单独的方法/类中，成为真实系统的一部分。
I think your approach of not testing a spike/prototype is just fine. But two ideas:
once you've finished your prototype and you know what you're doing to do, either throw it away and re-implement it test first, or write tests for the code you've already written.
when you've had more practice w/unit tests you might find it faster to create your prototype in a test than create a console app. I don't mean create a tests and a separate class w/the idea, I mean to explore w/code right in the test method. I've done this a number of times and I've been very happy with it. When I'm learning a new api or even a new language the test gives me the fastest feedback cycle for trying an experiment. Then once the code is working I can extract it out into a separate method/class to be part of the real system.
Even when you are writing a throw away prototype it can still be useful to think in terms of what the prototype will actually do, and start with tests that confirms that it does. Ensuring that the prototype can be tested will also shape the way the solution is approached.
Then when the code is thrown away you still have the tests.
I also have trouble starting with tests for prototypes, but when I have managed to do it I have always been glad I did.
I find that writing tests first does not work so well when I'm still construction the "story" of my code. It is hard to write tests when I'm unsure what the interfaces look like. I might write stub code to flesh out the classes and interfaces without thinking about tests. But I try to get to tests as quick as possible. I find it helps if I make notes of things I would test as I build the design, and then when my design is more solidified I go back to my notes and I make those tests firsts. That usually means the implementation and unit test code grow together, neither one before the other.
There is no single 'right way to do it'. However, I do think that Test Driven Development (TDD) would help in your case. I find that writing the tests first helps shape the API and makes the code cleaner. When you write tests first, you are thinking first about how the code will be called (the interface, or the 'what should this do') before thinking about the implementation (the 'how should I do it').
For example, imagine creating a CRM module. You might think that the first thing to do would be to get the customer that spent the most money. So, you would write a test:
Assert.AreEqual(Customer1, crm.GetMostValuableCustomer(), "most valuable customer not as expected");
You might then follow with something like:
Assert.AreEqual(new Customer[] {Customer1, Customer2, Customer3}, crm.GetCustomerByValue(), "GetCustomersByValue() not as expected");
So, the point is that you think about the code from a different perspective (as the consumer, not as the producer). I believe helps me to write much cleaner code, and I don't have to then go back and create regression tests later. I wish I had a better example, but hopefully you can see how working in this method might actually assist you in the prototyping stage.
发布评论
评论（7）
首要规则是：首先做风险最大的事情。
首先进行测试用例，隐含地认为，编码中最危险的部分是对正在创建的对象的接口和行为的错误沟通和误解。
对于许多项目来说，这很可能是正确的，并且 TDD 在这些情况下非常合适。
然而，在许多项目中情况并非如此，在这些情况下应用 TDD 是一个糟糕的选择。
如果你的最高风险是可用性，那么就不要再费劲单元测试了，而是做一些 UI 原型设计。
如果你的最高风险是性能，那么先做一些性能原型，不要担心接口。
这个清单还在继续。
首先做有风险的项目有很多优点：
不可避免地会失败的项目会在浪费许多资源之前早早结束。
陷入困境但可以挽救的项目尽早获得项目管理的关注，这样可以做一些好事。
陷入困境但可以挽救的
当项目失败风险较低时，组织的业务部门会更高地评价该项目； 项目被不必要地提前取消的可能性较小。
The over-arching rule is: Do the riskiest items first.
Doing the test-cases first is, implicitly, arguing that the riskiest part of the coding is miscommunications and misunderstandings of the interfaces and behaviour of the objects that are being created.
For many projects, that may well be true, and TDD is very appropriate in those cases.
However, in many projects that is not the case, and applying TDD in those cases is a poor choice.
If your highest risk is usability, stop futzing about with unit tests and do some UI prototyping.
If your highest risk is performance, do some performance prototypes first, and don't worry about interfaces.
This list goes on.
Doing the risky items first has many advantages:
Projects that are inevitably doomed die early, before many resources are wasted.
Projects that are in trouble but are salvageable get the project management focus early, when it can do some good.
The business side of your organization will value a project higher when it has a low risk of failure; there's less chance that it will be cancelled early unnecessarily.
“我听说通常建议在编写一行实现之前编写测试和模拟事物......我最终回去编写单元测试......这与你“应该做的”不同吗？”
既然你一开始就回答了你自己的问题，那么你并没有真正问这个问题，不是吗？
目标是测试第一。这就是它的工作原理。
假设我正在制作一个原型，但我不确定一切将如何工作。
但是，我确实知道一件事。它应该做什么。
写下它应该做什么的具体例子
这是我首先完成的测试用例。我可以将其正式化为单元测试吗？但是，我从一个验收测试用例开始。
对于我认为需要的每个示例，我都会写下该步骤的内容和结果
。
这些是测试用例。 我先做了它们。 在许多情况下，我可以将它们形式化为单元测试。
一旦我进行了测试，我就会返回每个步骤的示例并将其放入我的代码中。
一旦我进行了测试，我就会
我做了测试，然后编码。 在任何编码之前我没有进行所有测试。 我首先进行了测试，但不是以一种疯狂的全测试无代码方式。 我以增量测试-一点代码-一点的方式做到了这一点。 但一切都是先测试。
"I hear that it's often recommended to write tests and mock things before writing a single line of implementation.... I eventually go back and write unit tests... Is this different than what you're "supposed to do"?"
Since you started out with the answer to your own question, then you're not really asking that question are you?
The goal is test first. Here's how it works.
Say I'm making a prototype and I'm not sure how everything is going to work yet.
I do, however, know one thing. What it's supposed to do.
Write down a concrete example of what it's supposed to do. Concrete, specific inputs and outputs.
That's the test case. I did it first. Can I formalize this as a unit test? Probably not. However, I started with an acceptance test case.
Now, I can break the problem into pieces.
So I just start finding examples of each step that I think I need.
For each example of something I think I need, I write down what goes in and what comes out from the step.
Those are test cases. I did them first. In many cases, I can formalize those as unit tests.
Once I have a test, I go back to the example of each step and throw it into my code.
I did testing, then coding. I didn't do ALL the testing before ANY of the coding. I did testing first, but not in a crazy all-test-no-code way. I did it in an incremental test-a-little-code-a-little way. But everything was test first.
这很简单，答案是在原型设计期间。 在这个阶段，您对构建的系统还没有足够的了解，无法正确测试，而且无论如何，良好的实践表明原型代码应该是废弃的代码，因此在此阶段测试不会给您带来任何真正的好处。 但是，从原型设计中获得的理解将为您提供帮助，以便您在进入生产后可以进行有效的测试。
所以是的，如果你在原型之后进行测试，你的方法是正确的
This is simple, the answer is during prototyping. At this stage you don't understand the system your building well enough to test correctly, and anyways good practice says prototype code should be throw-away code so testing will not give you any real benefits at this stage. But the understanding gleamed from prototyping will help you so you can make effective testing once you enter production.
So yes your approach is correct, if you do test after prototypes
我认为你不测试尖峰/原型的方法就很好。 但有两个想法：
一旦你完成了原型并且你知道你要做什么，要么扔掉它并首先重新实现它测试，要么为你已经编写的代码编写测试。< /p>
当您进行更多单元测试练习时，您可能会发现在测试中创建原型比创建控制台应用程序更快。 我的意思并不是说创建一个测试和一个单独的类，我的意思是在测试方法中探索代码。 我已经这样做过很多次了，而且我对此非常满意。 当我学习新的 api 甚至新语言时，测试为我尝试实验提供了最快的反馈周期。 然后，一旦代码正常工作，我就可以将其提取到一个单独的方法/类中，成为真实系统的一部分。
I think your approach of not testing a spike/prototype is just fine. But two ideas:
once you've finished your prototype and you know what you're doing to do, either throw it away and re-implement it test first, or write tests for the code you've already written.
when you've had more practice w/unit tests you might find it faster to create your prototype in a test than create a console app. I don't mean create a tests and a separate class w/the idea, I mean to explore w/code right in the test method. I've done this a number of times and I've been very happy with it. When I'm learning a new api or even a new language the test gives me the fastest feedback cycle for trying an experiment. Then once the code is working I can extract it out into a separate method/class to be part of the real system.
即使您正在编写一个废弃的原型，思考原型的实际功能仍然很有用，并从确认其功能的测试开始。 确保原型可以进行测试也将塑造解决方案的实现方式。
然后，当代码被丢弃时，您仍然可以进行测试。
我在开始原型测试时也遇到了困难，但当我成功做到这一点时，我总是很高兴我做到了。
Even when you are writing a throw away prototype it can still be useful to think in terms of what the prototype will actually do, and start with tests that confirms that it does. Ensuring that the prototype can be tested will also shape the way the solution is approached.
Then when the code is thrown away you still have the tests.
I also have trouble starting with tests for prototypes, but when I have managed to do it I have always been glad I did.
我发现当我仍在构建代码的“故事”时，先编写测试效果不太好。 当我不确定接口是什么样子时，很难编写测试。 我可能会编写存根代码来充实类和接口，而不考虑测试。 但我会尽力尽快进行测试。 我发现，如果我在构建设计时记下要测试的内容，然后当我的设计更加固化时，我会回到我的笔记并首先进行这些测试，这会有所帮助。 这通常意味着实现和单元测试代码一起增长，而不是一个在另一个之前。
I find that writing tests first does not work so well when I'm still construction the "story" of my code. It is hard to write tests when I'm unsure what the interfaces look like. I might write stub code to flesh out the classes and interfaces without thinking about tests. But I try to get to tests as quick as possible. I find it helps if I make notes of things I would test as I build the design, and then when my design is more solidified I go back to my notes and I make those tests firsts. That usually means the implementation and unit test code grow together, neither one before the other.
没有单一的“正确的方法”。 但是，我确实认为测试驱动开发（TDD）会对您的情况有所帮助。 我发现首先编写测试有助于塑造 API 并使代码更清晰。 当您首先编写测试时，您首先考虑如何调用代码（接口，或“这应该做什么”），然后再考虑实现（“我应该如何做”）。
例如，想象一下创建一个 CRM 模块。 您可能认为要做的第一件事就是吸引花费最多钱的客户。 因此，您将编写一个测试：
Assert.AreEqual(Customer1, crm.GetMostValuableCustomer(), "最有价值的客户不符合预期");
然后，您可能会遵循以下内容：
Assert.AreEqual(new Customer[] {Customer1, Customer2, Customer3}, crm.GetCustomerByValue(), "GetCustomersByValue() 不符合预期");
因此，重点是您从不同的角度（作为消费者，而不是生产者）思考代码。 我相信可以帮助我编写更清晰的代码，并且我不必稍后返回并创建回归测试。 我希望我有一个更好的例子，但希望您能看到使用这种方法如何在原型设计阶段真正帮助您。
There is no single 'right way to do it'. However, I do think that Test Driven Development (TDD) would help in your case. I find that writing the tests first helps shape the API and makes the code cleaner. When you write tests first, you are thinking first about how the code will be called (the interface, or the 'what should this do') before thinking about the implementation (the 'how should I do it').
For example, imagine creating a CRM module. You might think that the first thing to do would be to get the customer that spent the most money. So, you would write a test:
Assert.AreEqual(Customer1, crm.GetMostValuableCustomer(), "most valuable customer not as expected");
You might then follow with something like:
Assert.AreEqual(new Customer[] {Customer1, Customer2, Customer3}, crm.GetCustomerByValue(), "GetCustomersByValue() not as expected");
So, the point is that you think about the code from a different perspective (as the consumer, not as the producer). I believe helps me to write much cleaner code, and I don't have to then go back and create regression tests later. I wish I had a better example, but hopefully you can see how working in this method might actually assist you in the prototyping stage.