Hacker News Reader

Comment by mdaniel | Hacker News Reader

TDD, as the top-most comment correctly points out <https://news.ycombinator.com/item?id=32509268>, relies on having requirements against which to test, and as very best I can tell, requirements aren't "Agile" because (pick one:) (the users don't even know what they want || there's never time to do it right, but there's always time to do it over)

don't even get me started on the "basic editor" versus IDE war; that's a topic that 100% of the time grinds my gears

View on HN

Sure there are other factors that are involved, but my point was, some coders are more deliberative while others are more exploratory. I'm in the latter group. I think by writing code. I do lots of refactoring and sometimes start over. Writing tests in the middle of that process would result in lots of thrown away test code and a much slower exploration of the problem space. Other coders think through problems first and know what they want before they start. They are more likely to benefit from something like TDD.

Agile isn't about requirements in the sense of "all behaviour of this project must be specified up front" but that doesn't mean for small slices of validated or to be validated behaviour we can't say "this is what it should do" (otherwise nothing sensible would ever get written?)

From that point of view, a developer has what they need to move forward with TDD (or any other process of their choosing).

I've been wanting a documentation system that lets me "cite" tests in support of a claim, such that when a test fails the programmer can see what claims that test was meant to support, which is crucial context in deciding how to fix the code, test, and/or docs.

You just need a testing framework that supports specifying context.

I write my JVM tests mostly using Spock[1] as it's absolutely great at letting me specify, and ecouraging me to do so, as much context as I can.

It may look something like this (this example is loosely based on Spock using Geb[2]):

    @Narrative('''
    Users can choose to authenticate using method A or B.
    This test makes sure that users can choose one or the other, go back and
    change their decision later, and complete the procedure with either method.
    ''')
    class AuthenticationMethodsSpec extends Specification {

        def 'Users can choose method A'() {
          given: 'the user goes to the login page'
          goTo(LoginPage)

          when: 'the user chooses method A'
          page.click('methodA')

          then: 'the user goes to the method A login page'
          at LoginMethodA
    }

Error messages are great too... and the tests, at least when written as above, with actual contextual information everywhere necessary, are much better than the usual JUnit abominations you're likely to find in Java shops.

It may look superficially similar to Cucumber, but it's IMO much better because it's just Groovy code (and I happen to really like Groovy, some people have trouble with it because it's "not exactly like Java"), no custom parsing of text-based stuff and other complex gimmicks.

[1] https://spockframework.org/spock/docs/2.1/index.html

[2] https://www.gebish.org/

Above all else, TDD requires that... ... ...you like working that way.

I dunno why the TDD folks specifically get so zealot-y about it being the one-True Way™. I'm happy that they've found something that they like and are passionate about, but, damn... it seems like they missed the episode of Power Rangers where you learn that different people will like different things than you do, and that that's okay. They don't have to be "wrong" for you to still enjoy your TDD.

Reply on news.ycombinator.com