Works great when you know what your doing before you start. That never actually happens in real life though.
And often if you box yourself into an API before you start implementing, it comes out worse.
I always learn a lot about the problem space once I start coding, and use that knowledge to refine the API of my system as I work.
Exactly, from my experience, most of the time (primarily when I need to do something new) I start writing code, when it starts working then I am starting to refractor it so it doesn't look like crap.
Perhaps TDD would make sense, when before any actual work starts, we would have POC phase to understand what needs to be done.
With my stakeholders TDD is nearly impossible. I mean it's possible, but doesn't make sense as they shuffle their specifications every other day. I implement, they decide they wanted something different, I refactor, they don't like it, I refactor, they accept, I write tests.
Please send help
Send help? We're all caught in the same fire.
I found a solution: I quit coding and became a school bus driver.
I feel you, man. 🍻
Yep. I’ve been there.
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.
TDD is actually helpful once you get the hang of it.
Yeah but getting the hang of it is the hard part. I don't know any dev in my company or my circle that uses it; we all did learn about it alright.
It is a lifesaver in some cases
I actually love using TDD in my real life development job…
Years of experience speaking:
If your end results are following this pattern, no one gives a fuck how you do
Make it maintainable should be up there too.
I’ve worked with projects that does the right thing, but no one can add new features to it because it’s a nightmare to work with. It’s at the level of not being able to move a button on the UI without breaking how the software interacts with the cloud.
Add make it cheap and you got yourself a deal
Pick two.
Nah, do all three. That should have been a numbered list.
It's criminally underutilized. Of course, one reason is that it's hard to TDD a moving target. Since it's also hard to get people to actually fucking specify things in a lot of real world cases, it's just one more thing you ought to do, but aren't allowed to.
I think you have a point with the moving target, but also I believe that development should pretty much always be a moving target. You should be refactoring your domain based on new experiences and new knowledge all the time. So, personally, I find integration tests much more useful, because they test the input and output of a system, rather than how it's implemented. I can change my domain without having to modify my tests and that makes changes to the domain much simpler.
That being said, I also definitely recognize the advantages of TDD, I just don't think it's a silver bullet; there's good projects for it and bad ones
I write my code, comment it out, write tests that fail, then uncomment my code, then do the proper TDD loop. Some folks get too strict about the process at the beginning saying that that a test that doesn't compile is still a failing test. My brain doesn't work like that.
It doesn't even sound great in theory. It sounds backwards in theory.
Yep :100:
expired
How would you know what you're going to need or what it can do before you code it ?
There's some things called software architecture, requirement engineering and software design. More dev teams should try this.
You don't write a whole app in tests and then write the whole app in code, you make tests for the functionality as you go.
The Test part of TDD isn’t meant to encompass your whole need before developing the application. It’s function-by function based. It also forces you to not have giant functions. Let’s say you’re making a compiler. First you need to parse text. Idk what language structure we are doing yet but first we need to tokenize our steam. You write a test that inputs hello world into your tokenizer then expects two tokens back. You start implementing your tokenizer. Repeat for parser. Then you realize you need to tokenize numbers too. So you go back and make a token test for numbers.
So you don’t need to make all the tests ahead of time. You just expand at the smallest test possible.
It also forces you to not have giant functions.
No, being unable to read giant functions is what forces me not to have giant functions.
My friend, let me tell you a story during my studies when I had to help someone find a bug in their 1383-line long main() in C… on the other hand I think Ill spare you from the gruesome details, but it took me 30 hours.
Case in point, actually. Whenever I'm forced to write a giant function, I always get nervous because it could be crawling with bugs that I have little hope of spotting.
I don't know if you're joking or not. I suppose tdd will help know what you need before you start.
Write code to test your code then repl build and run it anyways and smoketest it to see if it actually works
Sounds like activities for people who don't have real work to do. These tech layoffs cut deep because there was so much fluff in the industry. I sort of blame these companies that marketed devops too hard and oversold overcomplicated solutions, but it's also the fault of the tech leads advising managers.
There are circumstances that benefit from writing such tests, it's not so simple.
For sure but it also depends on how deep your wallets are to invest in that. Whether that means literal compensation or just your time.
It's definitely great in theory until you inherit a codebase with no tests, poor documentation, and numerous reported bugs already live in production. Even better if it was written by people hired because they could do other things better than they could code - which looking at some of the unlabeled wiring messes we were left, isn't saying a lot.
Good way to figure out how an unknown code base works is to add unit tests tho
It's also the only way to migrate architecture safely.
How does that even correlated?
I do it sometimes, especially when the bug is hard to reproduce and I know exactly what's causing it. Sometimes it's quicker to write the tests than to test manually.
I usually define all the tests I want to have but dont implement the testing logic. It helps me gather my thoughts like TDD would like you to do and I already have to start thinking somewhat about inputs and outputs. Its kind of a middle ground of TDD that works well for me.
TDD is up there with CBT if no one knows how to implement it properly
Cock and Ball torture simply must be done right
Elaborate.
OOP is another nice in theory practice.
The dev who don't know how to TDD their poorly designed object oriented spaghetti code are downvoting you, lol. Wear that with pride, but be sure to charge extra when it's time to fix their shit.
Post funny things about programming here! (Or just rant about your favourite programming language.)
