if you are building something small, like a two or so week project, then sure... skipping tests would allow you to get to the MVP faster.
the problem is that when you get to the 5th week you are really going to wish you had tests in place. making quick changes and then being able to run them against a test suite to ensure that everything is working correctly is valuable. this value goes up (in a non linear terms) as you add more and more code into the project.
to answer your question: at first writing no tests is faster, later on it becomes much slower. it is probably never better.
We skipped unit tests when we built desksnear.me for the rails rumble, but we DID have a cucumber test suite for integration testing. It wasn't that much of an impost for us, and it meant we spent more time coding, and less time manually testing stuff.
I think this approach fits well with the idea of an MVP - you express your minimum set of features in such a way that you can automatically test them, while still freeing yourself to throw away parts of the underlying code if you need to.
At the end of the day it's not an all or nothing thing, if there's a particularly gnarly bit of code that you want to unit test, then just unit test it!
If you have to ask, then the answer is probably no, you shouldn't have unit tests.
The purpose of MVP isn't to reduce quality in ordet to ship quickly. Also unit testing doesn't really incur an upfront cost - whether you write 50 tests or 1000, time spent is linear. So whether you have 100 features or 5, the time-cost of unit testing doesn't get all crazy/whacky.
You either believe in the value of unit tests - to flush out poor design choices and help in refactoring - or you don't.
gonna reply to myself...having read warren_s' comment on this, I tend to agree that a greater focus on testing behavior, rather than units of code, might be better suited to MVP (given the chance of recoding chunks of it).
6 comments
[ 6.2 ms ] story [ 34.0 ms ] threadthe problem is that when you get to the 5th week you are really going to wish you had tests in place. making quick changes and then being able to run them against a test suite to ensure that everything is working correctly is valuable. this value goes up (in a non linear terms) as you add more and more code into the project.
to answer your question: at first writing no tests is faster, later on it becomes much slower. it is probably never better.
I think this approach fits well with the idea of an MVP - you express your minimum set of features in such a way that you can automatically test them, while still freeing yourself to throw away parts of the underlying code if you need to.
At the end of the day it's not an all or nothing thing, if there's a particularly gnarly bit of code that you want to unit test, then just unit test it!
The purpose of MVP isn't to reduce quality in ordet to ship quickly. Also unit testing doesn't really incur an upfront cost - whether you write 50 tests or 1000, time spent is linear. So whether you have 100 features or 5, the time-cost of unit testing doesn't get all crazy/whacky.
You either believe in the value of unit tests - to flush out poor design choices and help in refactoring - or you don't.