mirror of
https://github.com/zhigang1992/fastai.git
synced 2026-03-29 00:18:59 +08:00
19 lines
1.3 KiB
Plaintext
19 lines
1.3 KiB
Plaintext
= Notes on fastai testing style
|
|
|
|
We chose pytest as a framework since it's more modern, concise, and https://www.slant.co/topics/2621/~python-unit-testing-frameworks[recommended by coders].
|
|
|
|
We also try to follow this suggestion from the http://docs.python-guide.org/en/latest/writing/tests/[python testing guide]:
|
|
|
|
____
|
|
Use long and descriptive names for testing functions. The style guide here is slightly different than that of running code, where short names are often preferred. The reason is testing functions are never called explicitly. square() or even sqr() is ok in running code, but in testing code you would have names such as test_square_of_number_2(), test_square_negative_number(). These function names are displayed when a test fails, and should be as descriptive as possible.
|
|
____
|
|
|
|
More generally, aim to write tests that also explain the code they are testing. A really good test suite can also serve as really good documentation.
|
|
|
|
== Testing patterns
|
|
|
|
* Do not use mock or fake objects. The library is nice enough that real versions of required objects can be used without prohibitive overhead.
|
|
* Keep test methods small and tidy, just like any other code.
|
|
* Aim to add a regression test as part of any bug fix PR.
|
|
* Add tests before refactoring, so they can help prove correctness.
|