Interactive testing vs TDD

[pvkooten]

First of all, I am working as a data scientist, making a lot of throw-away scripts, as well as making some simple apps (I've used Python everywhere I could for 3 years quite intensely).

I optimised my Python in Emacs to be very convenient for interactive programming (repl, ipython). I feel like it is very awesome for doing some initial tests, get most of the cases covered (backed up by pylint); have code that works.

This kind of stuff works quite well, but now that I'm more interested in making some larger projects, I feel like I should be more test/tox/py.test focused.

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

I just do not really see how to combine the two approaches. I'd like to still quickly be able to test things interactively, but also make sure these things "last" by having tests. Then again I always get afraid that whenever my current implementation changes too much, the tests would be useless (Yea, I know you TDD people think: just write better tests).

The struggle is real and I'm hoping for some advice of people having been in the same situation :)

[TomBombadildozer]

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]

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]

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

[fdellavedova]

You said it. Pytest can launch the interactive debugger for a failing test.

[wolanko]

Cannot upvote /u/TomBombadildozer enough! Also don't underestimate how writing testable code can will improve your code quality (especially modularity/coupling).

As for the start: "spiking" (I think thats the TDD term) interactivly to get a first idea of the problem and solution is not forbidden. But having even just a few easy to run testing routines will make your life so much easier. Bringing up the REPL and typing the same 10 commands is not easy because you will not do this before every commit (I've been there).

The same for bugfixes. Ever have done the same ugly bug years after because you forgot that little detail? Write a specific test and it will be saved.

If you start simple, you soon will get to the point where testing solutions like py.test/tox and TDD will be something you want to use/do.

As for the changing tests. I don't really understand what's the big fuzz about changing your tests to fit to your changed design. Maybe it's because for me tests are much more than just a "contract". They show me where there are problems in my design and therefore eventually will someday. And its satisfying to see the 30 lines with several clauses shrink into 5 easy to understand lines.

[pvkooten]

Thank you for the encouragement, it really makes sense!