I like TDD in theory and I spent so many years trying to get it perfect. I remember going to a conference where someone was teaching TDD while writing tic tac toe. Unsurprisingly, he didn’t finish in time.
The thing that I hate is people conflating TDD with testing or unit testing. They’re vastly different things. Also, I hate mocks. I spent so long learning all the test doubles to pass interviews: what’s the difference between a spy, fake, stub, mock, etc. Also doing it with dependency injection and all that. I much prefer having an in-memory database than mock what a database does. Last company I worked at, I saw people write tests for what would happen if the API returned a 404 and they wrote code that would handle it and all that. In practice, our HTTP library would throw an exception not return with a statusCode of 404. Kinda funny.
You obviously can’t always get replacements for things and you’ll need to mock and I get that. I just prefer to not use them if I can.
Also, TDD advocates love saying, you’re just not doing it well or you just don’t know enough.
I get it, you love TDD and it works for you and more power to you.
I definitely believe in testing and having resilient tests that will minimize changes upon refactoring, but TDD doesn’t work for me for most of the work I do. It works for some and I love it when it does, but yeah … sorry random long ramble.
After many failed attempts at TDD, I realized/settled on test driven design, which is as simple as making sure what you’re writing can be tested. I don’t see writing the test first as a must, only good to have, but testable code is definitely a must.
This approach is so much easier and useful in real situations, which is anything more complicated than foo/bar. Most of the time, just asking an engineer how they plan to test it will make all the difference. I don’t have to enforce my preference on anyone. I’m not restricting the team. I’m not creating a knowledge vacuum where only the seniors know how yo code and the juniors feel like they know nothing.
Just think how you plan to test it, anyone can do that.
This reminds me when a senior engineer asked me to write exception handling on a one-off python script, not a production code - just a script devs can use internally. The “handling” was that the program should exit when a file is not found. He wanted me to try the file open, except the file error, print “file not found” message and exit(1).
Guess what, genius. Python already does that for you. No need to write an extra wrapper needlessly.
Also, I hate mocks. I spent so long learning all the test doubles to pass interviews: what’s the difference between a spy, fake, stub, mock, etc.
Oh good grief. I haven’t even heard of half of those, and I’ve been writing code longer than most interviewers.
Also doing it with dependency injection and all that.
After struggling with several DI frameworks, I’ve come to the conclusion that DI is far too opaque and unpredictable to be useful.
OOP is also intentionally opaque, mind you, but debuggers can see through it if necessary, so that’s fine. DI, on the other hand, is opaque even to debuggers!
I much prefer having an in-memory database than mock what a database does.
I much prefer using the same DBMS for tests as the one used in production. That way, I can use its special features (like arrays as query parameters), and avoid bugs resulting from differences between DBMSes (which would only appear in production).
You obviously can’t always get replacements for things and you’ll need to mock and I get that. I just prefer to not use them if I can.
Indeed, and you usually can. Even if your system involves a bunch of services that normally run on different machines, who says you can’t spin up instances of them as part of the test? Tests are arbitrary code and can do anything that any other program can do, including starting subprocesses. Just be sure to terminate them once the test is finished, even if it fails.
I like to mock up dependencies with Docker Compose, then run all the tests against that. Keep the compose file in the repo, of course. I don’t tend to build a lot of real unit tests unless I’m doing something very novel and self contained. When you’re just assembling a service out of REST libraries and databases, integration testing is mostly what you want.
I like TDD in theory and I spent so many years trying to get it perfect. I remember going to a conference where someone was teaching TDD while writing tic tac toe. Unsurprisingly, he didn’t finish in time.
The thing that I hate is people conflating TDD with testing or unit testing. They’re vastly different things. Also, I hate mocks. I spent so long learning all the test doubles to pass interviews: what’s the difference between a spy, fake, stub, mock, etc. Also doing it with dependency injection and all that. I much prefer having an in-memory database than mock what a database does. Last company I worked at, I saw people write tests for what would happen if the API returned a 404 and they wrote code that would handle it and all that. In practice, our HTTP library would throw an exception not return with a statusCode of 404. Kinda funny.
You obviously can’t always get replacements for things and you’ll need to mock and I get that. I just prefer to not use them if I can.
Also, TDD advocates love saying, you’re just not doing it well or you just don’t know enough.
I get it, you love TDD and it works for you and more power to you.
I definitely believe in testing and having resilient tests that will minimize changes upon refactoring, but TDD doesn’t work for me for most of the work I do. It works for some and I love it when it does, but yeah … sorry random long ramble.
After many failed attempts at TDD, I realized/settled on test driven design, which is as simple as making sure what you’re writing can be tested. I don’t see writing the test first as a must, only good to have, but testable code is definitely a must.
This approach is so much easier and useful in real situations, which is anything more complicated than foo/bar. Most of the time, just asking an engineer how they plan to test it will make all the difference. I don’t have to enforce my preference on anyone. I’m not restricting the team. I’m not creating a knowledge vacuum where only the seniors know how yo code and the juniors feel like they know nothing.
Just think how you plan to test it, anyone can do that.
This reminds me when a senior engineer asked me to write exception handling on a one-off python script, not a production code - just a script devs can use internally. The “handling” was that the program should exit when a file is not found. He wanted me to
trythe file open,exceptthe file error, print “file not found” message and exit(1).Guess what, genius. Python already does that for you. No need to write an extra wrapper needlessly.
Oh good grief. I haven’t even heard of half of those, and I’ve been writing code longer than most interviewers.
After struggling with several DI frameworks, I’ve come to the conclusion that DI is far too opaque and unpredictable to be useful.
OOP is also intentionally opaque, mind you, but debuggers can see through it if necessary, so that’s fine. DI, on the other hand, is opaque even to debuggers!
I much prefer using the same DBMS for tests as the one used in production. That way, I can use its special features (like arrays as query parameters), and avoid bugs resulting from differences between DBMSes (which would only appear in production).
Indeed, and you usually can. Even if your system involves a bunch of services that normally run on different machines, who says you can’t spin up instances of them as part of the test? Tests are arbitrary code and can do anything that any other program can do, including starting subprocesses. Just be sure to terminate them once the test is finished, even if it fails.
I like to mock up dependencies with Docker Compose, then run all the tests against that. Keep the compose file in the repo, of course. I don’t tend to build a lot of real unit tests unless I’m doing something very novel and self contained. When you’re just assembling a service out of REST libraries and databases, integration testing is mostly what you want.