Related: I am a big fan of testing in my personal projects, but have never written a test for a client because they don't want to pay the additional hours. I have quoted about 25% - 30% of the time on writing tests , if they want them. Am I wrong? Ditto on documentation, no biters.
If you read Pragmatic Unit Testing[1], it talks about how writing tests actually takes less time than building a project without tests, in the long run.
First of all, it's possible to actually ship a product that was built with tests quicker than one that was not built with tests. This may not always be the case, but adding tests doesn't necessarily mean that it will add time, overall. It may feel like it's quicker to build an app without tests, but often the testing and bug fixing that happens at the end often exceeds the time it would have taken to build tests and eliminate most of the testing/bug fixing at the end.
Second, bypassing testing rarely saves time in the long run, especially for apps that continually require maintenance to existing code. Regression almost always occurs, and sometimes this isn't caught until production.
Unfortunately, it's a hard sell to clients, and depending on how well you are at covering this up, it often goes unrealized.
While I agree with you, it's a very tough sale if you're consulting for a company without a strong programming department. I find that companies plan for best-case scenario and deal with the consequences thereafter. Bugs are usually considered a programming mistake, even while acknowledging that poor planning plays a part.
I think it makes me faster long term, so yes I think you're wrong. I now think charging separately for tests is like charging extra for human-readable variable names or a well-factored code base.
If you're talking about writing tests after you've completed the implementation, then I wouldn't pay for those either. :)
Test-first development is a practice that helps you design software, and ultimately (arguably) reduces the number of defects. It's tied to development, so I wouldn't quote that separately.
If they don't want to pay for documentation, maybe they end up paying for a lot of support calls....
Your customer isn't paying for the code you write, they are paying for a finished product that works. How much code you write should be irrelevant to them.
In fact, one could argue it is far more dishonest to quote without testing since that does not include the maintenance costs that will be incurred by them after the initial product delivery, which will almost certainly be higher than a project with automated tests.
I completely disagree; you're quoting them the number of hours it will take you complete their project with the understanding that it will be at a certain level of quality. As long as you're both on the same page as to the expected quality, how you get to that point is your problem, not the client's. When you bill hours, you do include any time spent sketching some design, or debugging some problem, right? How is ensuring quality in a different fashion and including that time in your quote dishonest?
I would argue it's the same as trying to quote separately for debugging. You could take the approach that the unit tests are part of the implementation, but integration tests can be billed separately.
