Merge lp:~mcfletch/simplegc/testsuite into lp:simplegc
Status: | Merged |
---|---|
Merged at revision: | 273 |
Proposed branch: | lp:~mcfletch/simplegc/testsuite |
Merge into: | lp:simplegc |
Diff against target: |
42 lines (+36/-0) 1 file modified
tests/test_button.py (+36/-0) |
To merge this branch: | bzr merge lp:~mcfletch/simplegc/testsuite |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Sam Bull | Pending | ||
Review via email: mp+116183@code.launchpad.net |
Description of the change
Hi Sam,
One thing that came up in reviewing the GSOC projects so far is that we are way behind on testing and testability. So, here's a quick skeleton of a test suite. You'd install nose and globalsub (pip install --user nose globalsub, then run nosetests -sv in the root of the checkout to run the (two very simple) test cases.
globalsub isn't necessarily something you need to use, it's just what *I* use for most of my test suites. There are lots of similar projects (look for Python mock).
You'll notice in this test suite that there are very few assertions of expected results. Normally you want your code to be testable in such a way that you can assert functionality without needing to "peek into" the code. That is, if I run ".update( time )" where the mouse is over the button, I expect to see e.g. a "MouseIn" event show up, and I want my test case to test for that. Or I want to be able to call the public API to see what the current state is. That style of suite is not "unit testing", it's closer to functional testing, but for now I'd be happy if we could get a reasonable functional test suite covering the bulk of the functionality. A fairly extensive functional test suite will catch most *major* regressions, and will often point out API issues where you might want to refactor the code to allow for easier sub-classing or to break functionality into smaller units.
Enjoy,
Mike