quicky python continuous tests

pytest-watch is a fine quick “continuously run my tests” thing for Python in a tty. It’s nothing fancy, and the default UI is not perfect. But with -c and –no-beep and using –runner to run a custom command for your tests, it’s fine. Nice to not have to switch from my editor window to a console just to run the tests.

I’m envious of the NodeJS folks and their hipster test runners, they are very nice. Alternately I wish there were a good way to turn SublimeText into a bit more of an IDE with debugging and test output parsing. But after years of trying IDEs and going back to plain text editors, I think I’m not going to try to board that ship again.

 

6 thoughts on “quicky python continuous tests

  1. What are the sort of bugs you end up catching and fixing with this stuff? (genuine question, not some silly opener for a polemic).

  2. Are you asking in general what automated testing is good for? It’s such a different way of working I don’t know where to start. You know how you write some code, and then run it to see if it’s working? That’s what testing does too, only the “see if it’s working” part is itself a program you can run again and again.

    In the specific case of using pytest-watch, I was doing the “write the test first, then write the code to pass the test” style of development. So it’s not so much about catching bugs as it is knowing when I’ve accomplished my goal. It’s particularly good for refactoring / rewriting existing code, you can make sure it still works. More generally the test suite helps make sure I never introduce a new bug if I have a test for that part of it.

  3. >Are you asking in general what automated testing is good for?

    Heavens, no, sorry if I gave that impression.

    >I was doing the “write the test first, then write the code to pass the test” style of development.

    So, I use python for a big lot of very tiny things. What happens when you use it for a bigger thing? What do you run into? What helps and how? It’s an interesting thing to hear about, from recent practical experience.

  4. Ah I see. My thing is only medium size (~1500 lines of code). So the main thing I get from the test suite is the confidence that if I change one thing (say, the database schema for users) I don’t break other things (say, code that prints a user’s name).

    I also find the test suite is really helpful in absence of a type system. I seem to be making a lot of changes where I replace an integer with a tuple of two integers, for instance, and you can never quite be sure you update that everywhere without running the code. Tests are a way to run the code.

    1. >I also find the test suite is really helpful in absence of a type system

      I think this is the point where I race into the warm if deceitful embrace of C++ or Java.

  5. I’ve tried a bunch of tools over the years but keep coming back to simply running a shell loop – something like `while fswatch -1 …; do [whatever test runner/static asset compiler/etc. this project uses]; done` – because it’s portable and I can upgrade or replace any part of my toolchain without breaking of the other parts.

Comments are closed.