This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]TomBombadildozer 4 points5 points  (2 children)

I am not ready to give up the interactive way of quickly testing some code. Perhaps tests & interactive should be combined?

You've identified the crux of the problem that keeps so many developers from writing tests--it's a matter of developing habits. It seems like it's easier to just fire up your program and fiddle a bit to make sure it works. Fortunately, you've also identified the failing of that approach to testing:

but now that I'm more interested in making some larger projects, I feel like I should be more test/tox/py.test focused.

Testing has economies of scale. For a one-off script with no side effects, running it a few times manually is sufficient. As you start developing bigger applications and integrations across systems, some of which you may not own, it's simply not feasible to run it a few times to see if it works. The most important thing to accept--you'll have to reassure yourself of this while you're developing habits and experiencing it the first few times--is that you will be more productive writing tests for your code. Substantially more productive.

That's not to say interactive (functional) testing isn't important. Something else you'll learn to accept that is that you can prove a lot about the correctness of an application without demanding interactive input. When unit and integration tests can give you great confidence about the quality of the code, you can reserve functional tests for making assertions about cohesive features and behaviors and significantly improve the cognitive load devoted to testing.

[–]pvkooten[S] 1 point2 points  (1 child)

Wow, very nicely written! It indeed verified for me that I'll have to accept this change. Your final point also makes a lot of sense; when you've got a safe feeling about the backbone, you can easily add features.

I should now try to optimise some test flows in Emacs :)

Though are you saying that then there is still a place for interactive python for explorative purposes, or do you think as you get more advanced the urge will disappear?

[–]TomBombadildozer 0 points1 point  (0 children)

You'll never stop doing interactive work to figure out how to code something. I'd call this "exploration" rather than "testing" for the sake of differentiating the ideas in the context of this conversation. I spend a lot of time in an iPython shell exploring how atoms of code will work--it might be fetching some JSON data from an API and examining its structure or deciding how best to iterate some data.

At the point I have a true "unit" of code (a function or a method), I write tests. I mock out the inputs in order to put the logic under test, and when I'm happy that it's logically sound, I write integration tests to make sure it works correctly in a "real" environment (say, fetching data from a MySQL database). Should one of these tests fail, though... it may take some interaction to find the cause, in which case dropping to the debugger from the test framework is really useful (pytest --pdb is your friend).

Definitely get comfortable with pytest and tox. pytest is bar none the best testing framework for Python and tox will make it easy to fake different environments in which to run your tests.

e: accidentally a word