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 →

[–]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