[mason55]

> When time is a limiting factor, it's hard to get from "I know I should be doing this" to actually doing this.

If you don't have time to write tests then you've overscoped the features for the available time. Once you start treating testing as essential and budgeting a realistic amount of time to write test code (probably on the order of 1:1 feature code time:test code time) then you'll be able to get it done. Your total number of features will go down but quality will go up.

[esonderegger]

I'm sure I'm not the only one who got down the road to overscoped features by saying "gee, wouldn't it be cool if my users could access this info that's living in a mysql table" and threw something together with a little php mysql_query(SELECT...), and it worked! except for some edge cases with non-ascii characters and the fact that you knew you were opening yourself up to SQL injection attacks, but you weren't really concerned because you only have 100 users and they're already authenticated by a more robust system. Anyway, you decide to do it the "right way" and rewrite it using SQLAlchemy. In the mean time, your coworkers wonder why you've burned half a day rewriting a feature that worked just fine after you had only been spending 30 minutes on it.

Sorry, that was a long way of pointing out that us novice programmers often don't have good methods of determining how long something should take because we've never done it before.

[DougWebb]

Sorry, that was a long way of pointing out that us novice programmers often don't have good methods of determining how long something should take because we've never done it before.

That is basically the core difficulty in software estimation: none of us have good methods for determining how long something should take because most of the time we haven't done it before. If it had been done before in a way we can reuse, we'd reuse it. The meat of most projects is always something that's in some way new, even when the new bit is integrating a bunch of pre-existing parts in a new way.

[dasil003]

Another part of it is simply being good at automated testing. For me this was the biggest point of TDD—to force myself to learn to test anything and everything. At the end of the day all code must be tested, it's just a question of whether you are doing it manually or not. For one-off scripts and such manual testing is the sensible way to go, but for long-lived codes tests are an investment. Of course the value and necessity of tests varies quite a bit by language as well.

[slewis]

I agree with your point that it might be worth paring back features to improve code quality.

But there is no one true code to test ratio. If you're trying to become a better programmer be wary of dogma.

As posted here the other day, airbnb didn't have much testing until a year ago: http://nerds.airbnb.com/testing-at-airbnb/

I'm not saying either way is right or wrong, which is kind of my point.