[pbiggar]

Let me clarify. Nearly all programs should be tested, and have good test coverage. However, in this particular case your getting analysis paralysis from thinking too much about testing.

To overcome the analysis paralysis, just dont test. For now. Once you've started to get code out there and understand what you really need to test (by seeing what gets broken in production) it should be simpler to understand what you want to test and how to do it.

The most important thing is to ship. If testing is preventing you from shipping, skip the testing. The result of that is that in future, lack of testing will prevent you from shipping. At that point, it will be essential to improve your testing.

[matlock]

While there can be analysis paralysis having a clearly defined workflow and writing a test for that flow before you even implemented that feature worked great for us.

Writing a functional test at this point helps in understanding the problem space and interaction with the service quite well. And with the functional test in place it is a lot easier to see which other part of the new feature needs to have unit tests in place to make it very stable.

At least that has worked very well for us for a long time now