For most projects you should write automated tests. You should if you value your time anyway.
Much better to catch a bug locally from the tests than getting a call at 2:00 in the morning and fix it then.
Often I find myself saving time when I put time in to write tests. It may or may not take longer to implement what I'm building, but I (and others) will almost definitely save time maintaining it.
Reference: https://kentcdodds.com/blog/write-tests by Kent C. Dodds
Projects all over the Internet have switched from unittest or nose to pytest, including Mozilla and Dropbox.
Why?!
Offers powerful features such as:
assert
rewritingFeature | Pytest | Unittest | Winner |
---|---|---|---|
Installation | Third Party | Built in | Unittest |
Basic Infra | Can be only a function | Inheritance | Pytest |
Basic Assertion | Builtin assert | TestCase instance methods | Pytest |
Flat is better than nested | Function (1 level) | Method (2 level) | Pytest |
Can run each other test | Can run unittest tests | Can't pytest test | Pytest |
Test Result on console | Error Highlight, code snippet | Only line error, no highlight | Pytest |
Multi param test | Yes, parametrize, keep flat | Yes, sub-test, increase nesting | Pytest |
Test setup | fixture: module, session, function | Template Method: setup, tearDown | Pytest |
Name Refactoring | poor, because of name conventions | rich, regular object orientation | Unittest |
Running Failed Tests | built in (--lf, --ff) | your own =,( | Pytest |
Marks | built in | your own =,( | Pytest |
All of the tests are kept in tests and separate from the package source files in src. This isn’t a requirement of pytest, but it’s a best practice.
Brian Okken
I like to keep functional and unit tests separate because functional tests should only break if we are intentionally changing functionality of the system, whereas unit tests could break during a refactoring or an implementation change.
Brian Okken