开始TDD-挑战?解决方案?建议? [英] Beginning TDD - Challenges? Solutions? Recommendations?

问题描述

好的，我知道已经有关于

OK, I know there have already been questions about getting started with TDD.. However, I guess I kind of know the general concensus is to just do it , However, I seem to have the following problems getting my head into the game:

• 在使用集合时，即使基于仿制药等我们知道"其正常工作的情况下，是否仍会测试明显的添加/删除/插入是否成功?
• 某些测试似乎要花很长时间才能实现.例如，在处理字符串输出时，是否有更好"的方式来进行这种处理? (例如，在解析之前测试对象模型，将解析分解为小操作，然后在此处进行测试).在我看来，您应该始终测试最终结果"，但这可能千差万别，并且设置起来很繁琐.
• 我没有可以使用的测试框架(工作不会花钱)，所以我可以更多地练习".是否有任何可免费用于商业用途的优质产品? (目前我正在使用良好的'ol Debug.Assert :)
• 可能是最大的..有时我不知道会发生什么. .我的意思是，您得到了批准，但我始终担心我可能会错过考试.您是否更深入地尝试破坏代码，还是保留它，等到以后一切都掉下来(这会花费更多)..

• When working with collections, do will still test for obvious add/remove/inserts successful, even when based on Generics etc where we kind of "know" its going to work?
• Some tests seem to take forever to implement.. Such as when working with string output, is there a "better" way to go about this sort of thing? (e.g. test the object model before parsing, break parsing down into small ops and test there) In my mind you should always test the "end result" but that can vary wildly and be tedious to set up.
• I don't have a testing framework to use (work wont pay for one) so I can "practice" more. Are there any good ones that are free for commercial use? (at the moment I am using good 'ol Debug.Assert :)
• Probably the biggest.. Sometimes I don't know what to expect NOT to happen.. I mean, you get your green light but I am always concerned that I may be missing a test.. Do you dig deeper to try and break the code, or leave it be and wait for it all fall over later (which will cost more)..

因此，基本上，我在这里寻找的不是"做到这一点"，而是更多"我这样做了，遇到了问题，并以此解决了这些问题" .. 个人经历:)

So basically what I am looking for here is not a " just do it " but more " I did this, had problems with this, solved them by this ".. The personal experience :)

推荐答案

首先，当您第一次开始尝试以编码风格使用TDD时，感到沮丧是正常的.只是不要灰心和戒烟，您需要花一些时间.在思考如何解决代码问题方面，这是一个重大的范式转变.我喜欢想到它，就像当我们从过程式编程转向面向对象的编程时一样.

First, it is alright and normal to feel frustrated when you first start trying to use TDD in your coding style. Just don't get discouraged and quit, you will need to give it some time. It is a major paradigm shift in how we think about solving a problem in code. I like to think of it like when we switched from procedural to object oriented programming.

第二，我认为测试驱动的开发首先是一项设计活动，该活动用于通过创建一个首先描述将要公开的API以及如何使用的测试来充实组件设计的工作.它的功能.该测试将帮助塑造和塑造被测系统，直到您能够封装足够的功能来满足您要执行的任何任务.

Secondly, I feel that test driven development is first and foremost a design activity that is used to flesh out the design of a component by creating a test that first describes the API it is going to expose and how you are going to consume it's functionality. The test will help shape and mold the System Under Test until you have been able to encapsulate enough functionality to satisfy whatever tasks you happen to be working on.

请牢记以上段落，让我们看一下您的问题:

Taking the above paragraph in mind, let's look at your questions:

1. 如果我在被测系统中使用的是集合，那么我将设置一个期望值，以确保调用该代码以插入该项目，然后断言集合的数量.我不必在内部列表上测试Add方法.我只是确保在调用添加项的方法时调用了它.为此，我在测试框架中添加了一个模拟框架.
2. 测试字符串作为输出可能很乏味.您无法解释所有结果.您只能根据被测系统的功能来测试期望的结​​果.您应该始终将测试分解为要测试的最小元素.这意味着您将进行很多测试，但是测试又小又快，仅测试了应该进行的测试，而没有其他要求.
3. 有很多开放源代码测试框架可供选择.我不会争论哪个是最好的.只需找到您喜欢的一个并开始使用它即可.
   • MbUnit
   • nUnit
   • xUnit

1. If I am using a collection in my system under test, then I will setup an expectation to make sure that the code was called to insert the item and then assert the count of the collection. I don't necessarily test the Add method on my internal list. I just make sure it was called when the method that adds the item is called. I do this by adding a mocking framework into the mix, with my testing framework.
2. Testing strings as output can be tedious. You cannot account for every outcome. You can only test what you expect based on the functionality of the system under test. You should always break your tests down to the smallest element that it is testing. Which means you will have a lot of tests, but tests that are small and fast and only test what they should, nothing else.
3. There are a lot of open source testing frameworks to choose from. I am not going to argue which is best. Just find one you like and start using it.
   • MbUnit
   • nUnit
   • xUnit

我在第一个问题的答案中向您介绍了嘲笑术语.当您将模拟引入到您的TDD军械库中时，它极大地简化了测试，从而使那些不属于被测系统的零件抽象出来.以下是有关模拟框架的一些资源:

I introduced you to the mocking term in the answer for question one. When you introduce mocking into your arsenal for TDD, it dramatically makes testing easier to abstract away the parts that are not part of the system under test. Here are some resources on the mocking frameworks out there are:

• 最低订量:开源
• RhinoMocks :开源
• TypeMock :商业产品
• NSubstitute :开源

• Moq: Open Source
• RhinoMocks: Open Source
• TypeMock: Commercial Product
• NSubstitute: Open Source

一种帮助使用TDD的方法，除了阅读有关该过程的信息外，还要观察人们的行为.我建议您在 DNRTV 上观看JP Boodhoo的屏幕广播.检查这些:

One way to help in using TDD, besides reading about the process, is to watch people do it. I recommend in watching the screen casts by JP Boodhoo on DNRTV. Check these out:

• Jean Paul Boodhoo进行了测试驱动开发的第1部分
• Jean Paul Boodhoo进行了测试驱动开发的第2部分
• 让·保罗·博杜(Jean Paul Boodhoo)揭开了设计模式的神秘面纱第1部分
• 让·保罗·博杜(Jean Paul Boodhoo)着《揭开设计模式的神秘性》第2部分
• 让·保罗·博杜(Jean Paul Boodhoo)着《揭开设计模式的神秘性》第3部分
• 让·保罗·博杜(Jean Paul Boodhoo)着《揭开设计模式的神秘性》第4部分
• Jean Paul Boodhoo谈揭开设计模式的神秘面纱"第5部分

• Jean Paul Boodhoo on Test Driven Development Part 1
• Jean Paul Boodhoo on Test Driven Development Part 2
• Jean Paul Boodhoo on Demystifying Design Patterns Part 1
• Jean Paul Boodhoo on Demystifying Design Patterns Part 2
• Jean Paul Boodhoo on Demystifying Design Patterns Part 3
• Jean Paul Boodhoo on Demystifying Design Patterns Part 4
• Jean Paul Boodhoo on Demystifying Design Patterns Part 5

好的，这些将帮助您了解如何使用我介绍的术语.它还将介绍另一个名为 Resharper 的工具，以及该工具如何促进TDD流程.在进行TDD时，我对这个工具的推荐不够.似乎您正在学习该过程，而您正在发现使用其他工具已经解决的一些问题.

OK, these will help you see how the terms I introduced are used. It will also introduce another tool called Resharper and how it can facilitate the TDD process. I couldn't recommend this tool enough when doing TDD. Seems like you are learning the process and you are just finding some of the problems that have already been solved with using other tools.

如果我不通过在在实用程序员上进行测试驱动的开发.

这篇关于开始TDD-挑战?解决方案?建议?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！