One of the goals for kilo is to have an increased number of functional tests located within projects. In discussion with Steve Baker I said:
Ideally I'd like to see two things happen:
- Better tests running on Jenkins from project trees.
- Easier ways for people to effectively use those tests locally.
Actually I guess three things but this last I'm not expecting to make a lot of headway on:
- Doing a paradigm shift in testing so that people aren't writing tests that are class methods (in the unittest module style), but are instead just functions (as often done with nose or pytest). This can lead to a lot of increased verbosity but to me that would be a win: the tests that I've looked at have been incredibly difficult to decipher: too much magic and activity in super classes, too much mocking. As a result the tests are quite useless as a way of learning the systems being tested.
For functional testing one can argue that the transparency afforded by explicit1 tests is a good way of defining/exposing the behavior that is being tested.
-
Explicit in this context is a suite of things: limited or no mocks, eschewing OO, verbosity for the sake of learning and reuse. ↩