This is the problem with writing unittest after the code - you then realize your code is difficult to test. Writing the tests before the code (well, really "along" the code - you don't write all tests before start coding, but still you dont write a line of code before you have a test for it) makes sure you don't have such a problem.
Now even with the "test first" approach you do have to test methods that don't return anything. The way to do so is to test for the expected side effects. Some of these side effects are easy to test - in your above case, you can test the value of self._count
before and after the call to nextImage
, depending on your object's state (_imagesInList
and animFlag
mostly). Where it gets more difficult is if you want to test that nextImage
does actually call showImageByPath
with the correct arguments, and with your current design the only way to do so is to monkeypatch showImageByPath
for the tests. Testing showImageByPath
will require patching / mocking self.label.setPixmap()
, etc.
As others already pointed there are a couple mock/stub libs that can help, but they won't solve all possible testability issues and you may have to rethink your design to make things easier - like not hardcoding the call to QtGui.QLabel()
in buildUI()
but have some way to "inject" the desired componant (QtGui.QLabel()
or a mock) instead. As a general rule, testable code has very few hard-coded dependencies, few side effects, and lot of small classes with short methods (instead of huge classes with long methods).