Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>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 <em>all</em> 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.</p> <p>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 <code>self._count</code> before and after the call to <code>nextImage</code>, depending on your object's state (<code>_imagesInList</code> and <code>animFlag</code> mostly). Where it gets more difficult is if you want to test that <code>nextImage</code> does actually call <code>showImageByPath</code> with the correct arguments, and with your current design the only way to do so is to monkeypatch <code>showImageByPath</code> for the tests. Testing <code>showImageByPath</code> will require patching / mocking <code>self.label.setPixmap()</code>, etc.</p> <p>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 <code>QtGui.QLabel()</code> in <code>buildUI()</code> but have some way to "inject" the desired componant (<code>QtGui.QLabel()</code> 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). </p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload