You know what has improved the quality of my code? Having every error on my live servers emailed to me. I feel compelled to fix it because I know that an actual user has had a problem.
I tried to do unit testing for a project. I'd write a method, then write some tests for it. Some observations:
* I thought that writing the tests would give me refactoring ideas for the actual methods. It did not.
* Running my test suite prior to each deploy saved me from shipping a bug once. Once.
* Writing tests is fucking boring.
This was all code that I knew the purpose of in advance. I have no idea how one writes tests when doing exploratory coding.
"I have no idea how one writes tests when doing exploratory coding."
You're probably already writing tests, especially when you're doing exploratory coding. How much code do you really write before you check to see if something works? You're almost certainly doing something. Maybe it's just a small main program where you validate that some methods are giving you the output you expected, or maybe it's a simple web form that you populate with mock data to verify it's persisting to a database. Unless you wait until the entire functionality is ready before a trial run (and if you're doing exploratory coding, there's no such thing as "ready" anyway), you are writing something to test during iterations.
Instead of throwing these tests away, keep them somewhere and run them periodically. If they break, figure out why - and either fix the code, or change the test. When you're done, you'll have a bunch of unit tests.
(just a quick note - the process I described above works extremely well for some situations, but poorly for others. Some frameworks make it a real hassle to write unit tests. The process I described also is not TDD, it's more of a write a little, test a little approach, which feels more natural to me. I also don't really like to use TDD, especially for exploratory coding).
You're right: I write a little, do a test run of the code to see what comes back, fix it if it doesn't work, write a bit more and so forth. And I see how saving those little tests could be useful.
There are testing packages for a couple languages (Python and Lua, for sure) that let you just copy in the text directly from the interpreter and use them as regression tests.
Comments
You know what has improved the quality of my code? Having every error on my live servers emailed to me. I feel compelled to fix it because I know that an actual user has had a problem.
I tried to do unit testing for a project. I'd write a method, then write some tests for it. Some observations:
* I thought that writing the tests would give me refactoring ideas for the actual methods. It did not.
* Running my test suite prior to each deploy saved me from shipping a bug once. Once.
* Writing tests is fucking boring.
This was all code that I knew the purpose of in advance. I have no idea how one writes tests when doing exploratory coding.
"I have no idea how one writes tests when doing exploratory coding."
You're probably already writing tests, especially when you're doing exploratory coding. How much code do you really write before you check to see if something works? You're almost certainly doing something. Maybe it's just a small main program where you validate that some methods are giving you the output you expected, or maybe it's a simple web form that you populate with mock data to verify it's persisting to a database. Unless you wait until the entire functionality is ready before a trial run (and if you're doing exploratory coding, there's no such thing as "ready" anyway), you are writing something to test during iterations.
Instead of throwing these tests away, keep them somewhere and run them periodically. If they break, figure out why - and either fix the code, or change the test. When you're done, you'll have a bunch of unit tests.
(just a quick note - the process I described above works extremely well for some situations, but poorly for others. Some frameworks make it a real hassle to write unit tests. The process I described also is not TDD, it's more of a write a little, test a little approach, which feels more natural to me. I also don't really like to use TDD, especially for exploratory coding).
You're right: I write a little, do a test run of the code to see what comes back, fix it if it doesn't work, write a bit more and so forth. And I see how saving those little tests could be useful.
There are testing packages for a couple languages (Python and Lua, for sure) that let you just copy in the text directly from the interpreter and use them as regression tests.