[qsort]

I'm fine with encouraging proper tests. On a base level, TDD encourages tests, so it's overall fine, at least in principle.

My main gripe with it is the second-order concern that it encourages testing practices that are frankly not very intelligent.

How you should approach testing depends on what kind of function you are testing. Pure functions of their inputs should be tested with property-based tests. If you have

    bool isPrime(int n)

the whole rigmarole of "make a test that fails, then write the least amount of code that makes it pass" brings you to something like:

    assertFalse(isPrime(1));
    assertTrue(isPrime(2));
    assertTrue(isPrime(3));
    assertFalse(isPrime(15));

and so on, where what you really want is to say something like:

    for all 1 < i < n . n % i != 0

This obviously works less well when you have to deal with the real world, but even in that case TDD leaves you with a patchy and inflexible approach.

[drewcoo]

TDD works just fine with property-based tests, with each case representing an equivalence class. I like to randomly select from those classes because that eventually double-checks that I set my boundaries correctly. I often additionally pin the class boundaries in place.

https://en.wikipedia.org/wiki/Equivalence_partitioning

[skybrian]

Interesting, could you say more about how you go about this? I’m in the middle of figuring out how I want to do property-based testing for a parser, using fast-check.