On Wed, Jan 14, 2009 at 10:57 AM, Jake b <ninmonk...@gmail.com> wrote: > >> > 2) Do you have two seperate unittests ? (A) One is ran every time source >> > files are compiled, and a second, (B) slower one is ran at a longer >> > interval >> > for slow tests ? >> >> Such separation is rarely necessary. > > Something I started on, requires rendering. It's not a huge delay, but I > don't want it happening every time I hit f5, while the other tests are fast > that they can every time. > > I'm not totally sure how I'm going to handle this. For now I'm manually > running the slow one, but.
In my system, all of my tests are categorized, and I have a flag in the run tests script that determines which categorys I want. While debugging, I only run "new" tests (any tests I am working on or recently added, I tag as new). Before I check into version control, I make sure to run all of the tests first, but setting the flag in the run tests script to all categories. Running all of the tests does take a while (more than a minute), but the slow tests don't delay my debugging/coding. Another option, which might have merit, is to completely separate rendering tests and other unit tests. You can have one runner that runs the rendering tests, and another runner for everything else. I think rendering is a bit fuzzy as a unit test. You should prefer tests that don't have to render to those that do, and structure code in such a way that you can test as many things without rendering as possible. For instance, animation code doesn't need to render to check and make sure self.frame is incrementing properly. But, there are certainly cases where rendering needs to be tested. Just make sure to only test it when necessary. Example (semi-real): I have 20ish tests for positioning an object. If I were to draw the object in each test, it would be very slow. Instead, the 20 tests check the result of a get_screen_pos() rather than render the object outright. Most of the logic that used to be in the object.draw() method is refactored to the get_screen_pos method. That way I can get by with just a few tests of object.draw() itself, and know that since it uses get_screen_pos (which is fully covered by the other tests), that draw() is well covered as well. Any of your tests or test files that import the module are pretty much inherently checking for compiler errors, so there is no need to test for the compiler explicitly. That cookbook example sounds like it is less about compiling, and more of a way to implicitly run tests when the application runs.