Migrate tests to pytest away from unittest

[dshemetov]

Context

In our delphi-epidata tests we’ve been using a mix of pytest and unittest. This has mostly worked seamlessly, because most of the features we use from unittest, like setUp and tearDown methods and unittest.skip are supported by pytest. I want to make a case for moving away from using unittest:

• you can’t use pytest.mark.parametrize to parametrize a method from a test class that subclasses from unittest.TestCase (I got errors I wasn’t able to untangle)
  • an example use case for parametrize: you have a test that takes a CSV file as input and checks that it's processed correctly; the test can be kept the same, parametrized over multiple CSV files, and pytest will naturally separate any failing CSV files into their own test (no need to hunt in a for-loop for the failing CSV)
• likely there’s other features of pytest that aren’t fully supported when you mix the two

I got a yes from @melange396 and a yes from @krivard (minus preferring unittest's typed assert statements [see migration below]; maybe we can see how to mitigate this).

Migration

Migrating over to pure pytest has a simple part and a hard part:

• the simple part is renaming setUp to setup_method and tearDown to teardown_method and @unittest.skip to @pytest.mark.skip
• the hard part is converting unittest.assertEqual type checks to regular assert statements. The pytest philosophy is to always use assert and report error context depending on the types and the operand. Searching for self.assert in the delphi-epidata codebase yields 1582 results, so this would take a bit of time

Help

I'll do the easy part in a PR soon. For the hard part, any and all help is welcome! Feel free to add partial PRs and link them to this issue! Also feel free to edit this post to organize the work, so we know which parts of the codebase still need to be migrated.

[dshemetov]

Another unanticipated part:

• unittest.subTest is used 328 times in our tests, so these would need to be migrated
• on the plus side (or maybe this is a minus), pytest already doesn't support them (you need to use pytest-subtest to get this feature), so we're not really getting any use out of these subtests anyway; it may be better to use pytest-check, which allows multiple failures per test
  • another benefit of pytest-check is unittest-style validation functions