You may know I love to hate tests. Well not the tests actually, what I hate is the TDD culture.

DBMS schema in my app dictates a key can either have a value, or be omitted - it can't be null, and all queries are written with that in mind (also they're checked compile-time against schema). But tester failed to mock schema validation, inserted a bunch of null keys with mock data, actually wrote assertions to check those keys are null (even though they never should be), and wanted me to add "or null" to my "exists" queries.

No, we don't need more tests, and you're not smart with your "edge cases" argument. DBMS and compiler ensure those null values can never exists in our DB, and they're already well tested by their developers. We need you to stop relying on TDD so much you forget about the practical purpose of the code, and to occasionally break from the whole theoretical independent tests to make sure your testing actually aligns with third-party services some code uses.

And no, we don't need more tests to test your mocks, and tests to test those test, and yo dawg, I heard ...

  • 6
    Don't blame TDD, blame morons
  • 1

    While morons are morons - you should handle nulls in your db, unless the db itself prevents null to be written.
    In case someone accesses your db not through your code, it might break your code. again - morons.
  • 3
    @magicMirror (probably the DB scheme defines "not null")
  • 0
    @kescherRant Indeed, and for some cases it defines even more complex constraints like pattern validation for strings, min / max for numbers, or even compound constraints across keys (either of the two must exist, but not both) - basically, things that can't be represented as interfaces and types in most programming languages.
  • 0
    @alexbrooklyn Morons are indeed one problem. The other problem is the whole abstraction and separation of code at the core of TDD, which makes it really easy to miss the bigger picture.
Add Comment