Identify different types of tests

[slarse]

It would be good to know what to look out for. These are the types of tests we know of so far:

• unittest.TestCase test classes.
• print statements for manual inspection.
• Doctests
• Asserts in main functions
• Random functions with only asserts
• Code just lying about in the top level of the module

[mnil2]

The list above essentially holds for the first half of folders (.vs to graphs). Almost every single test is a manual-inspection print from either the main function or the top level. Exceptions to this are VERY FEW.

Important note regarding doctests, though. Some doctests aren't ever actually run, making it harder to spot them. For example, in ciphers/simple_substitution_cipher.py, there are doctest docstrings, but doctest itself isn't even imported. So look for that.

Also note that the amount of untested files is actually significant. The majority/all of the files in the following folders are untested: boolean_algebra, ciphers, data_structures/hashing, data_structures/queue, digital_image_processing, dynamic_programming, and file_transfer_protocol. There are also some in data_structures in general, and in graphs.

[rouwaydhanna]

Found that some tests, in addition to print statements, also plot graphs. For example in maths/newton_raphson.py.

other/anagrams does not print to stdout, but writes to a txt file.

Other than that, most were tested with print statements.

[slarse]

@martinnilsson93 Do you think we need to look for additional stuff to do? It seems to me like, in terms of a pure re-factor emanating from a single issue, this one is pretty dang big.

I found that some unit tests were actually discoverable and runnable from the get-go, let's try to get some "before" test logs before we start tomorrow. That's totally off topic but whatever.

[mnil2]

Do you think we need to look for additional stuff to do? It seems to me like, in terms of a pure re-factor emanating from a single issue, this one is pretty dang big.

@slarse I think it's big enough. I mostly mention the untested files so people know up-front to expect them and where not to direct much attention. Esp. for splitting up the work it's useful to know where there is basically nothing to do.

Regardless, if we do find ourselves starved for work, there are several files that, though not really tested, are basically just demonstrations and that take minimal to no input. These can usually be retooled into tests quite clearly. I think there are many ways to go an extra yard on the refactor.

[slarse]

Alright, nice!

[mnil2]

The test migration #46 is done