You’re goddamn right.
Years of experience speaking:
- Make it work
- Make it right
- Make it fast
If your end results are following this pattern, no one gives a fuck how you do
Pick two.
Nah, do all three. That should have been a numbered list.
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.
Jesus Christ
Add make it cheap and you got yourself a deal
Also make it yesterday.
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.
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.
Yep :100:
OOP is another case of nice in theory.
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.
TDD is great when you have a very narrow use case, for example an algorithm. Where you already know beforehand: If I throw A in B should come out. If I throw B in C should come out. If I throw Z in an error should be thrown. And so on.
For that it’s awesome, which is mostly algorithms.
In real CRUD apps though? You have to write the actual implementation before the tests. Because in the tests you have to mock all the dependencies you used. Come up with fake test data. Mock functions from other classes you aren’t currently testing and so on. You could try TDD for this, but then you probably spend ten times longer writing and re-writing tests :-/
After a while it boils down to: Small unit tests where they make sense. Then system wide integration tests for complex use-cases.
then you probably spend ten times longer writing and re-writing tests
This is always what I’ve seen personally when people use TDD. And it’s worse because the inevitable time crunch towards the end of the project means the developers stop maintaining the tests, which renders all of the work put into the tests up to that point useless.
That’s not a problem with unit tests, that’s a problem with project management
Well put.
Totally agree.
I think we should all strive to do better. Unit tests, mock-ups, UX design, 2 week sprints with actual working deliverables, well documented use cases, every thing neatly stacked in Jira, dev,test,staging,prod environments, continuous integration and every thing else we are told to do.
Then reality sets in……
With all that said, 25 years as a dev, this utopian environment is almost impossible to find unless forced by regulatory compliance. Medical devices, life critical systems, etc. or if you have big piles of money.
In my experience, those things tend to be forced by project managers who believe the highest law of the land is proper scrum. Unsurprisingly, this makes all the devs miserable with no way to change anything because “this is just how it’s done”.
Hahaha. Yea. Been there too.
I always start with the basics for my test cases. Like, every test case has a name, and
assert(true)
in the body.It’s also great for bug fixes. Write that sucker first and you have an easy way to reproduce the issue and check whether it’s fixed.
Yeah, I’m constantly recommending junior devs to use TDD specifically for this. I don’t recommend it for anything else. If they don’t write the test first, it’s possible that the test will end up testing the wrong thing and thus they can’t be sure they really did fix the bug.
Sometimes it’s hard to tell where to write the test ahead of time, so sometimes a slight variation I do is to write the test after (usually because it was such a struggle to figure out where the bug is), but when I’m testing it, I’ll comment out the fix or whatever and make sure the test fails.
I mean, it sounds more like “The messier your project, the more difficult the unit testing”. What you’re describing sounds like issues with SRP and LoD. Which will inevitably happen as big projects get rushed, but let’s place the blame where it belongs: rushing.
Yes unit tests take longer up front, but for projects that you need to update and maintain for a long time, they’re a huge boon.
You can’t do everything with a unit test obviously.
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?
It doesn’t even sound great in theory. It sounds backwards in theory.
Elaborate.
Sounds like you either need to establish better task parameters or you need to gain more experience programming.
This is very true.
Unfortunately most product managers SUCK at designing or making software.
Agile tries to fix this be supporting frequent iteration.
Unfortunately most programmers SUCK at writing good code.
TDD tries to fix this by forcing the consideration of end results (testing) at the beginning. It forces programmers and product teams to actually think and work. Make clear design decisions earlier on, but not to the point of waterfall.
It’s just a giant cesspool of failure due to human laziness that usually falls on the shoulders of QA.
Bottom line, making good software is hard. It takes time. But the market won’t support slow development. The business and sales teams remind me of Veruca Salt in Willy Wonka.
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.
bad habits are hard to break.
It is a lifesaver in some cases
expired
Works great when you know what your doing before you start. That never actually happens in real life though.
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.
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.