Is TDD a meme? I really struggle to come up with tests for my software unless I already have an initial version of the actual code. Designing it as I write tests leaves too many questions unanswered. Maybe if you're doing something very simple or that you already did many times it can work, because the design already exists in your head.
TDD is a meme because it rewards programmers to write tests that they know will succeed instead of trying to break the system.
writing tests is a humrit
>>108607447TDD is real, but writing tests before you write code is a bit of a meme. Along with or after is fine.
>>10860744710/10 bodyShame about the tatsNever understood why women are so willing to deface their own bodies
>>108607459Bruh, if you have no testers and you are doing the dev and testing, you need this. Blame will fall on you, so better think of all the edge cases. I worked at one such place, they expected too much quality and the code was great.
>>108607469You can think of all the edge cases without TDD.
>>108607467She's a live action Meg Griffin
>>108607469>if you have no testersthen you're working for a sweat shop
>>108607475Yes, but when making related changes, it shouldn't break existing features. It also allows you to refactor your code.
>>108607447TDD is a crutch for retards
>>108607623>it shouldn't
>>108607447When you know the answers up front (and they're easily testable) you can use TDD.But that's not too often.
>>108607447TDD should be PERF BENCHMARKING not driven development
>>108607447>>108607467>>108607539I could teach her a thing or two.
>>108607464TDD means writing tests before code.>>108607822Correct
>>108607467>10/10 bodyif you're gay and like no hips or tits
>>108607447It's a meme, yes.
>>108607539>>108608191She will pin you to the ground and rape you and you won't be able to do anything about it but scream
>>108607447Everyone here craps on TDD, exactly like devs in the workplace. I spent 2 years on and off trying to understand it. I forced myself to do it step by step and succeeded.10 years later, no other dev I’ve worked with could grasp TDD. This is what you’re up against. This is why people crap on TDD.For me, I went from 3 weeks coding an app and weeks afterwards debugging bugs.To 6 weeks coding and zero debugging. Most of my TDD apps are still running at companies I left years ago. Team leads hate me, managers are frustrated at me. I deliver software slower than my colleagues, but I have no support load.I spent a day watching my colleague trying to debug a bug. I cloned his repo, wrote a test and saw the bug immediately. He spent 2 weeks finding the bug. A client changed their upload format, no one knew until the system broke. I used their file, ran my tests, saw the bug, wrote another test, fixed the code and pushed a new release in 5 minutes and money flowed again. The IT manager pushed TDD after that - but none of the devs could understand it.
>>108607447> I really struggle to come up with tests for my softwareThat’s not TDD. To explain it, you start from nothing and think of the first step along the critical path. Write a test to validate that and run it to see red. Write the smallest piece of code to pass the test. If you’re writing more than that, stop.Return to the test and create another test for that extra code. When the tests pass, create another test for another item along the critical path. Repeat and soon the app is built.It’s difficult for 99% of devs to comprehend this. As one of my mentors said “Once you see it - you will never go back to coding the old way.” I spent a few weeks on and off trying to teach a senior dev who was “the best coder” in the company that he was doing testing wrong. He couldn’t understand, instead saying mocking was everything he needed. I explained that he wasn’t testing the code, he was testing the mocking of the code, and it would always test fine. I pushed a breaking change into the repo, and all the tests passed.Production (“UAT” actually) was now broken and no one knew what the problem was. I ran my tests and it showed exactly what the issue was. He looked at my screen and looked at his screen. His comment was “roll it back” and said nothing more on the topic to me for weeks.
>>108607464>>108607822Agree with this.TDD is the correct approach if you somehow already know the answer to the problem you're trying to solve ahead of time. Which is almost never outside of exercise.Otherwise I write the code first and defer writing the tests until as late as possible to avoid having to rewrite both the code+tests when refactoring.Doing library level tests usually first and then integration tests following that. So something like a combination of unit tests followed by cross-unit tests.
TDD where you build the tests extremelly incrementally is a waste of time,>hurr durr I need a red test on my default constructor before I start implementing!I used to like less retarded TDD, but there's the tendency to just make the tests pass. Your primary goal, and primary line of defense should still be logic. Write tests, but focus mostly on code that makes logical sense instead of curve fitting to test results.
>>108608313Man, in college they wanted us to write tests for every little line we wrote and I thought TDD was just a waste of time...We were also supposed to write the test before the implementation
>>108608313so do TDD if you want people to hate you, got it
>>108608385This sounds strange. Why do you have your own personal test suite for the project that noone else is running? And if it's not your project, how did you quickly write all the tests to troll your colleague? And if you added them after you saw you coworkers' code it wouldn't even be TDD.
>>108607467Tats and a lack of tits.Patty needs a boob job.
>>108608732That’s your take-away? You get invited to many parties?
>>108607447TDD works great for utility functions, if you try to use it for something like web frontend,you will need to get familiar with Automation QA skillset, because the only way to test that stuff meaningfully is E2E tests.It would be really cool though, it's just takes a lot of extra time.There are retards that do those stupid mocked vdom UI tests, but those are fucking useless.So if you don't have capacity for E2E, then better just save time and don't do anything at all.
>>108608764You had to be there. Strange was normal.
are we just talking doing proper unit testing or actual TDD?
It's like a lot of software engineering concepts. They take an idea that makes a good deal of sense (write tests that guide your development and force you to clarify what results you're looking for) and turn it into an autistic dogma. The whole loop where you're writing tests that you're intentionally trying to fail is completely retarded.
>>108609204No, but also people at work don't hate me.
>>108607447TDD is nonsense.- write the tests first- write the code- fix all the tests because the tests don't hold up anymore- write more tests for all the edge cases you discovered while writing the code- fix the code because your new tests don't passpeople that rely on tests like "once the tests pass it's all good" are a problem
>>108607447TDD isn't a memeTDD helps you write code that is PERFECTTDD is basically a superpower! You don’t just write code, you prove it works before it even exists. Bugs don’t get fixed… they get prevented from ever being born.Your code quality goes through the roof! Every line is battle-tested, intentional, and lean. No fluff, no guesswork, just pure, crystalline engineering excellence.Refactoring becomes fearless, rip your system apart, rebuild it, optimize it. Your test suite stands guard like an army, instantly telling you if you broke anything.Documentation writes itself, your tests are the spec. Anyone can read them and immediately understand what the system does without digging through vague docs or tribal knowledge.You ship faster by slowing down. Paradoxically, the discipline of TDD eliminates endless debugging, regression chaos, and late-night firefighting. It’s not just a workflow, it’s enlightenment for developers.
>>108609567this has to be bait
>>108609238TDD helps you write code that is PERFECT… at writing tests. The actual program? That’s more of a side quest. Why solve a problem directly when you can first write 14 failing tests that describe a universe where the problem is already solved? It’s basically a superpower, yes - the power to spend twice as long implementing half as much. You don’t just write code, you perform a ritual. First, you imagine a bug. Then you write a test for it. Then you write code to satisfy the test. Then you realize the test was wrong. Then you fix the test. Then you fix the code. Then you question your life choices. Bugs don’t get prevented - they get politely invited into a very structured environment where they can thrive under supervision. Your code quality goes through the roof, assuming the roof is made of fragile assumptions baked into tests you wrote before you understood the problem. Every line is “battle-tested,” meaning it survived combat against expectations that may or may not reflect reality. Refactoring becomes fearless, because at some point you stop feeling anything at all. Rip your system apart, rebuild it, optimize it - and then spend the next hour updating 73 tests that were tightly coupled to your previous implementation details. The test suite doesn’t stand guard; it files complaints. Documentation writes itself, which is great, because no one wants to write actual documentation. Instead, future developers get to reverse-engineer intent from a collection of oddly specific assertions like should_handle_edge_case_when_flag_is_true_and_input_is_7. Crystal clear. You ship faster by slowing down, except for the part where you don’t ship faster. But you feel like you should be shipping faster, and honestly, isn’t that what matters? It’s not just a workflow - it’s enlightenment. The kind where you transcend productivity entirely and achieve a higher plane of writing tests about code you haven’t written yet.
>>108609707Lmao
Tried TDD for one simple small project, implementing a Solitaire game.90% of dev time was wasted rewriting tests any time I slightly modified any function signature or interface, it's probably one of the worst ways to program unless you're doing very basic CRUD work.I'd say it actually can make developers produce badly designed code since it punishes any kind of refactoring.
>>108607447testing is a meme
>>108607447she is so fucking mid.
>>108610474TDD would be perfect for implementing some abstract data structures or algorithms or math utility functions. This is the kind of problems that are naturally approached with having some example inputs and outputs beforehand, so it's only natural to put them as initial test cases.
>>108607447Testing in general is a meme. I just write code that works. Not sure why so many people have trouble with that.
TDD is meme, its a bullshit productivity method too.It's based around the false assumption that you have well defined requirements and stable interfaces, both of which you won't have 99% of the time. Good luck getting a business to assign a business analyst to your fucking project, because I've never had it happen.It also bloats up the codebase and makes refactoring a major pain in the ass, and gives you a false sense of security from "passing" tests. The TDD cult members will often say "You're just doing it wrong!", much like communists everytime it fails.In my 10+ years of development I have never seen any evidence or studies that show it actually reduces bugs, reduces production incidents, saves time or increases code quality. Infact pajeets will often write tests to pass their own broken code. What it will do is slow your velocity down to a crawl the more tests you have.
>>108607447Cure.
>>108607447i want to put my nose right there
>>108607447This isn't /fit/, but I'd absolutely sniff that midget.
I never done it enough to really grasp how it truly is. They try to force that and pair programming (for every single line of code written) at work, but the amount force they use is here a little and there a little.I just could never get into TDD. Pair programming though, I have strong feelings about that.
>>108607447idk, i could never get into it. whatever test i start with changes so much as i write the real code that it feels like i'm wasting time editing the test constantly and would've been better off waiting til i finished the codemaybe it works well if you have an extremely well-defined task for a mature codebase and you know exactly the expected inputs/outputs before starting. but for something like that, writing the actual code is basically a formality since you know exactly what you're going to do without needing to think about it, it's barely even TDD because you've already written the code in your head
>>108607464>writing tests before you write code is a bit of a memei'd always learned that this was literally what TDD meant, not that just having tests is TDD by default
>>108607475Yes, but when making related changes, it shouldn't break existing features. It also allows you to refactor your code. >>108612602I think this is what they teach at school. But just tweak it a bit. They just want things to work and don't care how you do it.
>>108609707>Your code quality goes through the roof, assuming the roof is made of fragile assumptions baked into tests you wrote before you understood the problem.this is what I take to mean by people using the phrase "[to] break through [a] glass ceiling"
>>108612626>Yes, but when making related changes, it shouldn't break existing features. It also allows you to refactor your code.That's just tests in general. TDD is the method you write the code and tests, not the tests themselves.
>>108612647You're responding to a chatgpt post, bro.
>>108607447Sort of. Test driven development is fine. Test driven design is a meme. Often people do development driven design, and in that mode, writing tests before writing code requires a lot of overhead that adds little value. At the end of the day you want to be able to text your code in every meaningful way. Doing TDD helps to enable hitting that goal, but writing tests after you've hammered out a design and adjusting your design to be testable is also viable if you have the discipline to not half-ass your tests (said discipline is also required for TDD.)
>>108607447is the point of TDD not for regression testing?personally, I don't even see the purpose for formal languages. what works for me besides using a pencil is using OOP design patterns and even though TDD has design requirements as a prerequisite, I prefer to proof design during implementation or function prototyping (i.e. writing macros) doing incremental prototyping... usually this looks like proofing statements and writing out the proof in the comments so that there aren't any assumptions further along in finalizing the software version.I unfavorably end up throwing away so much code and doing tests without units, using print statements throughout wherever I encounter testing. for a long time, this is what I thought TDD was, and didn't bother writing design documents or using a notebook. other than >>108611077 what is the point besides regression testing?is there a better means to an end for validating software? I mean besides using the existing tooling like profiling and static analysis. my interests center around dynamic analysis methodology and I've had a budding interest in CI/CD over the years except that I've not once implemented a pipeline for that, just Makefile targets for automating these sorts of things.I picked up Ada during my salad days and put it down fairly quickly for the same reason as TypeScript. that is because the toolchain environment is severely crippled compared to what exists for C, and is why I stick with using it and not C++ if I don't have to. in my day, I seem to remember there being more available tooling for C# or Objective-C like Java for making really big graphs and reports. I'm certain I'm misremembering those things and this was in like 2009, because those are likely SDK functionality for paid development environments. if I wasn't at all interested in creating portable software, I would easily switch to writing everything in x86_64 assembly language other than needing to completely reinvent the wheel constantly.
>>108612723you don't think I could tell?
>>108612738https://lewiscampbell.tech/blog/260414.htmlclanker tl;dr>In "Saying Goodbye to Agile," Lewis Campbell argues that the modern software industry has moved from the original Agile manifesto toward hollow, process-heavy methodologies. The blog post advocates abandoning the "Agile" label in favor of genuine, high-involvement development practices that restore digital and intellectual autonomy. Read the full post at lewiscampbell.tech.
>>108607447Tests? Just code your program well and use it yourself before you ship it.
>>108610474>90% of dev time was wasted rewriting tests any time I slightly modified any function signature or interfaceNot anon, but that's ironic because the whole point of TDD is to quickly fix problems before you write any code.But it seems like you are writing more test code than you have implementation code it seems.You are not supposed to write code that compiles while writing the tests, you just write the tests first, realize problems while writing the tests, then fix the API before you end up re-writing the implementation with the new function signatures and etc. It helps if your tests resemble real world code as much as possible, but if your code can't replicate real world usage, you shouldn't write a test, since your usage / application should be the test instead.
>>108612893there are a great number of cases where this doesn't work in practiceI refuse to elaborate
