3 ms·
> but he said he was just using it for some home projects I think here lies the biggest problem. For small/hackish projects you barely get any benefits from te
by legulere 11y ago
> but he said he was just using it for some home projects
I think here lies the biggest problem. For small/hackish projects you barely get any benefits from test driven development but still have the higher costs. Test-driven development means that you will spend more effort while developing, but will have to spend less on maintaining in the long run.
The fun part about home projects is that you don't really have to think about maintenance at all and you can just hack things away until they work for you.
PS: you should write out acronyms once in the beginning of an article
- LordDragonfang 11y agoI spent the majority of the article thinking it stood for the "top-down design" that my intro to programming professor was so fond of.
- EdSharkey 11y agoMy home projects become tragic when they get past the trival size and I haven't been TDD'ing and designing all the way through. I think part of my problem is that I cannot devote a consistent level of effort every week to my current home project. Sometimes I'll leave and when I come back to it, I'm lost without a test suite and wind up rewriting huge swaths of it. Really good tests also serve as up-to-date documentation of your design. If you code in Java or Groovy, check out the Spock Framework. Spock tests read like a story. I wish there was a Spock-like DSL for JavaScript development.
- vorg 11y agoSpock hacks into Groovy's AST to make labelled expressions have special meanings: def "adder-test"() { given: "a new Adder class is created" def adder = new Adder(); expect: "Adding two numbers to return the sum" adder.add(3, 4) == 7 } It could all easily break if the Groovy parser or AST is updated. And very clunky, which says something about Groovy's design post v 1.5.