# Testing and pytest --- ## Testing  --- ## Testing For most projects **you should write automated tests**. You should if you **value your time** anyway. --- ## Testing Much better to catch a bug locally from the tests than getting a call at 2:00 in the morning and fix it then. --- ## Testing > 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 --- ## unittest - Included in python on version 2.1 (April 17, 2001) - Originally inspired by JUnit and has a similar flavor as major unit testing frameworks in other languages --- ## What is pytest? - A robust Python testing tool, pytest can be used for all types and levels of software testing. - pytest can be used by **development teams**, QA teams, independent testing groups, individuals practicing TDD, and open source projects. --- Projects all over the Internet have switched from unittest or nose to pytest, including Mozilla and Dropbox.  --- Why?! --- ## What is pytest? Offers powerful features such as: - `assert` rewriting - a third-party plugin model - powerful yet simple fixture model that is unmatched in any other testing framework. --- ## Comparsion <div style="font-size:12px;"> <table> <thead> <tr> <th>Feature</th> <th>Pytest</th> <th>Unittest</th> <th>Winner</th> </tr> </thead> <tbody> <tr> <td>Installation</td> <td>Third Party</td> <td>Built in</td> <td>Unittest</td> </tr> <tr> <td>Basic Infra</td> <td>Can be only a function</td> <td>Inheritance</td> <td>Pytest</td> </tr> <tr> <td>Basic Assertion</td> <td>Builtin assert</td> <td>TestCase instance methods</td> <td>Pytest</td> </tr> <tr> <td>Flat is better than nested</td> <td>Function (1 level)</td> <td>Method (2 level)</td> <td>Pytest</td> </tr> <tr> <td>Can run each other test</td> <td>Can run unittest tests</td> <td>Can't pytest test</td> <td>Pytest</td> </tr> <tr> <td>Test Result on console</td> <td>Error Highlight, code snippet</td> <td>Only line error, no highlight</td> <td>Pytest</td> </tr> <tr> <td>Multi param test</td> <td>Yes, parametrize, keep flat</td> <td>Yes, sub-test, increase nesting</td> <td>Pytest</td> </tr> <tr> <td>Test setup</td> <td>fixture: module, session, function</td> <td>Template Method: setup, tearDown</td> <td>Pytest</td> </tr> <tr> <td>Name Refactoring</td> <td>poor, because of name conventions</td> <td>rich, regular object orientation</td> <td>Unittest</td> </tr> <tr> <td>Running Failed Tests</td> <td>built in (--lf, --ff)</td> <td>your own =,(</td> <td>Pytest</td> </tr> <tr> <td>Marks</td> <td>built in</td> <td>your own =,(</td> <td>Pytest</td> </tr> </tbody> </table> </div> Ref: https://github.com/renzon/pytest-vs-unittest --- ## Some useful tips >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 --- ## Some useful tips >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 --- ## Let's get started  <!-- ## Using assert statements pytest includes a feature called `assert` rewriting that intercepts `assert` calls and replaces them with something that can tell you more about why your assertions failed. -->