Test-driven development appears to be testing of the requirements. What about white-box unit testing? Isn't it important to have tests that will exercise the various code paths?
I'm not sure what the term "white-box unit testing" is intended to mean. We have a big problem with terminology in testing. I recommend Gerard Meszaros' XUnit Test Patterns book as an excellent reference for correct terminology.
Gojko Adzic has an initiative to come up with "the right names for the right things".
Unit tests are tests which verify the design of a tiny piece of code. Test-driven development is a design tool, not a test tool, but has the happy side effect of serving as automated regression tests going forward. Component tests verify the code architecture, making sure the units communicate properly. Both types of tests are used by and for the programmers.
Requirements are really tested at what some people call the acceptance test level, also known as story tests or customer-facing tests. We also write these tests in advance of writing the code, using examples of desired and undesired behavior provided by the business experts. Ideally, these can be specified as executable, automatable tests, which may test the business logic, the user interface functionality, the database access. These tests will exercise more paths through the code than the unit and component tests.
We also need end-to-end tests which test through all the layers of the application. These may be done manually or it may be possible to automated some or all of them. Most importantly, we need to do exploratory testing. Only a person with critical thinking skills and a desire to learn more about the system can do adequate exploratory testing. Unfortunately, many teams never have time for exploratory testing, because they spend all their time doing manual regression tests.
I'm not sure what the term "white-box unit testing" is intended to mean. We have a big problem with terminology in testing. I recommend Gerard Meszaros' XUnit Test Patterns book as an excellent reference for correct terminology.
Gojko Adzic has an initiative to come up with "the right names for the right things".
Unit tests are tests which verify the design of a tiny piece of code. Test-driven development is a design tool, not a test tool, but has the happy side effect of serving as automated regression tests going forward. Component tests verify the code architecture, making sure the units communicate properly. Both types of tests are used by and for the programmers.
Requirements are really tested at what some people call the acceptance test level, also known as story tests or customer-facing tests. We also write these tests in advance of writing the code, using examples of desired and undesired behavior provided by the business experts. Ideally, these can be specified as executable, automatable tests, which may test the business logic, the user interface functionality, the database access. These tests will exercise more paths through the code than the unit and component tests.
We also need end-to-end tests which test through all the layers of the application. These may be done manually or it may be possible to automated some or all of them. Most importantly, we need to do exploratory testing. Only a person with critical thinking skills and a desire to learn more about the system can do adequate exploratory testing. Unfortunately, many teams never have time for exploratory testing, because they spend all their time doing manual regression tests.
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/11379785/viewspace-690496/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/11379785/viewspace-690496/
1940
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
