Writing test cases in SymPy

Sumith edited this page Nov 8, 2015 · 3 revisions

As and when a bug is fixed or a new module is implemented, test cases need to be written. Questions like whether there is any need to follow certain rules for writing test-cases, how many test-cases should be written and about the increasing test-suite time, have been answered below:

There are no general rules that would apply to every situation. Some general things, though:

  • Tests should provide coverage of the code. This is more than just lines covered (which is what the coverage tool tells us). It really means we should cover all the possible code paths.

  • As one instance of this, we should try to test any corner cases. Corner cases usually represent trivial input, so they generally are very fast tests, but they are important because it's easy to code them wrong.

  • As for the speed of the tests, we should avoid tests that are slower than necessary (like don't use a very large expression if a small expression would test the same thing). However, more important is coverage than test speed. Don't be afraid to add a lot of tests.

  • It's also a good idea to stress test every once in awhile. Currently we don't do this enough in SymPy. This means tests that are larger than usual. It could also mean tests that are only fast if the code is properly tuned, to test against performance regressions.

  • Tests often test more than one thing implicitly (e.g., a test may test the output of a function, but also implicitly test that the function does not raise an exception). However, it should be clear from a test what it is explicitly testing.

For the discussion see this

Clone this wiki locally
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.