This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Automated unit testing

Automated unit testing
by on (#66167)
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?

by on (#66189)
Not automated, but I've written several little tests for the various library routines I use in the test ROMs. They test aspects of the interfaces of the routines, like what registers they save, and effects they have after being run. Really helpful for establishing confidence that they work properly.

by on (#66192)
I do lots of quick and dirty testing with a debugger and printing to the screen. The nametable output code for my game is prototyped on FCEUX with Lua (Now on its second draft that uses smarter ideas and no 16-bit math). Both drafts have dummy inputs for testing.

One of my eternal projects has Python embedded in C++. Of course you can use the Python command line to initialize the game objects and check their states without running the exe. It might even be possible to run the game engine blind to test collision and AI, though I'd have to think about it more.

by on (#66198)
I try to anticipate every possible output based on every possible appropriate input, and try to stop inappropriate input before it even happens. So basically, no, I pretty much just wing it.

by on (#66199)
strat wrote:
It might even be possible to run the game engine blind to test collision and AI, though I'd have to think about it more.

Collision is one thing that shouldn't be too hard to test automatically. Make a level with just the objects you want to test, some of them in overlapping positions. Run your collision detection. If the detected objects are the ones you expected to be detected, good. Otherwise, the build failed.