There is a discussion on Slashdot about how to make testing easier.
Advocates of test-driven development claim that every subroutine in a product should have a unit test. This is a corresponding program that sets up several inputs for the subroutine and compares them to its expected outputs. You write the test before you write the subroutine itself, and any errors in the test are treated like compiler errors. Even nondeterministic behaviors in a system, such as AI, can be replaced with mock objects for the duration of the test. Use of this methodology leads to fewer defects that reach acceptance testers ("play testers") and fewer defects that reach customers.
Blargg has made a bunch of automated unit tests for NES emulators. But does anyone use automated unit tests when developing NES software?
Advocates of test-driven development claim that every subroutine in a product should have a unit test. This is a corresponding program that sets up several inputs for the subroutine and compares them to its expected outputs. You write the test before you write the subroutine itself, and any errors in the test are treated like compiler errors. Even nondeterministic behaviors in a system, such as AI, can be replaced with mock objects for the duration of the test. Use of this methodology leads to fewer defects that reach acceptance testers ("play testers") and fewer defects that reach customers.
Blargg has made a bunch of automated unit tests for NES emulators. But does anyone use automated unit tests when developing NES software?