Unit testing a script that opens a file

python, unit-testing

Solution

That's not what unit-testing is about!

- Your file doesn't represent an UNIT, so no you don't test the file or WITH the file!

- your unit-test should test every single method of your functions/methods which deals with the a)file-processing b) calculations

- it's not seldom that your unit-tests exceeds the line of code of your units under test.

Unit-test means (not complete and not the by-the-book definition):

- minimalistic/atomic - you split your units down to the most basic/simple unit possible; an unit is normally a callable (method, function, callable object)

- separation of concern - you test ONE and only ONE thing in every single test; if you want to test different conditions of a single unit, you write different tests

- determinism - you give the unit something to process, with the beforehand knowledge of what it's result SHOULD be

- if your unit-under-test needs a specific enviroment you create a fixture/test-setup/mock-up

- unit-tests are (as a rule of thumb) blazingly fast! if it's slow check if you violated another point from above

- if you need to test somethin which violates somethin from above you may have made the next step in testing towards integration-tests

- you may use unit-test frameworks for not unit-testings, but don't call it unit-test just because of the use of the unittest-framework

This guy (Gary Bernhardt) has some interesting practical examples of what testing and unit-testing means.

Update for some clarifications:

"1. Would I test that the file opened?"

Well you could do that, but what would be the "UNIT" for that? Keep in mind, that a test has just two solutions: pass and fail. If your test fails, it should (ideally must) have only one reason for that: Your unit(=function) sucks! But in this case your test can fail, because: * the file doesn't exist * is locked * is corrupted * no file-handles left * out of memeory (big file) * moon- phase and so on.

so what would a failing (or passing) "unit" test say about your unit? You don't test your unit alone, but the whole surrounding enviroment with it. That's more a system-test! If you would like to test nontheless for successful file-opening you should at least mock a file.

"2 ... How would I unit test the calculations? Do I literally have to manually calculate everything and test that the result is right?"

No. You would write test for the corner- and regular-cases and check the expected outcome against the processed one. The amount of tests needed depends on the complexity of your calculations and the exceptions to the rule.

e.g.:

def test_negative_factor(self):
   assert result 

def test_discontinuity(self):
   assert raise exception if x == undefined_value

I hope i made myself clearer!

Problem

I've written a script that opens up a file, reads the content and does some operations and calculations and stores them in sets and dictionaries. How would I write a unit test for such a thing? My questions specifically are: - Would I test that the file opened? - The file is huge (it's the unix dictionary file). How would I unit test the calculations? Do I literally have to manually calculate everything and test that the result is right? I have a feeling that this defeats the whole purpose of unit testing. I'm not taking any input through stdin.

Original source