Improve the Design and Flexibility of Your Project with Extreme Programming Techniques
필요한 내용만 간추려 봤습니다.
Lessons Learned
The most important lesson you should have learned so far is that TDD is simple. In fact, TDD is a great for obtaining a better understanding of any new language, technology, or component that comes your way. It allows you to decide the size of steps you need to take. An expert might have taken bigger steps and, using his experience, avoided some of the intermediate steps that we took. When things start to go wrong, however, you always have the option of going back and doing it again, taking smaller steps. There are number of other things you may have noticed about TDD:
• The tests document the code. We can see exactly what Quad does by looking at the tests.
• We can measure progress by the tests passed. Each piece of functionality is proved by a test, so anyone can run the tests to see that claims of progress are well founded.
• The tests make everyone confident about changing the code. Even though you might be a novice C# programmer working on a class written by an expert, running all of the tests will reassure you that you haven’t broken anything.
• Mistakes, like passing the length and width as parameters to Area and Perimeter rather than to the constructor, are corrected by refactoring.
• When you apply TDD in the real world, you’re going to generate lots of tests, so you need to organize your testing using a tool like NUnit.
Using TDD in the Real World
One of the first things to consider when using TDD since a commercial project is deciding how to organize your programs so that the production code can be easily separated from the code used to test it. You want to run your programmer tests throughout the product’s development and yet be able to easily remove them for the purposes of releasing the code.
Another issue you might encounter is the difficulty of testing GUI applications driven by mouse and keyboard input. For example, how do you write a test that simulates a user clicking a dropdown list and then verifies that it is populated with a given list of country names?
The answer to both of these problems lies in dividing the code into appropriate components that can be built, tested, and deployed separately. For example, rather than building Quad as a class contained in the same executable file as the main application, it could have been contained in a separate library (.dll). This would have allowed us to develop both the test program and the domain program as separate executables (.exe) that shared a common library (.dll) containing Quad. Note that if you’re only building a library, NUnit and your test suite can be used as the interface, rather than requiring a separate harness.
The idea of keeping the main program very simple and putting the business complexity into classes contained in a library can also help solve the problem of testing GUI applications. One of the rules of TDD is that you don’t test third-party code, so there is no requirement for you to test the GUI framework classes, although it’s sometimes useful to test interfaces, particularly if they’re a bit flaky. This means you can catch the user event in a class that you know works and then pass it through for processing to the class you’re developing. Again, you can separate the test program and the domain program into separate executables sharing the common libraries that form the bulk of your development effort.
Let’s see how this might work in practice by using TDD to develop a combobox list for a simple forms application.
자세한 내용은 다음의 MSDN Magazine 사이트에서 확인해보세요.
http://msdn.microsoft.com/msdnmag/issues/04/04/ExtremeProgramming/default.aspx
— 블로그 이전하기 전 코멘트
즐똥:
영어라 … ^^ ; 2005/02/19 23:33
독재자:
TDD에 관심 있으시면 한번 읽어보세요. 예제만 보셔도 될듯. 2005/02/19 23:53
