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

>>108607447
TDD is real, but writing tests before you write code is a bit of a meme. Along with or after is fine.

>>108607447
10/10 body
Shame about the tats
Never understood why women are so willing to deface their own bodies

>>108607459
Bruh, 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.

>>108607469
You can think of all the edge cases without TDD.

>>108607467
She's a live action Meg Griffin

>>108607469
>if you have no testers
then you're working for a sweat shop

>>108607475
Yes, but when making related changes, it shouldn't break existing features. It also allows you to refactor your code.

>>108607447
TDD is a crutch for retards

File: ricky.jpg (34.9 KB)

34.9 KB JPG

>>108607623
>it shouldn't

>>108607447
When you know the answers up front (and they're easily testable) you can use TDD.
But that's not too often.

>>108607447
TDD should be PERF BENCHMARKING not driven development

>>108607447
>>108607467
>>108607539
I could teach her a thing or two.

>>108607464
TDD means writing tests before code.
>>108607822
Correct

>>108607467
>10/10 body
if you're gay and like no hips or tits

>>108607447
It's a meme, yes.

>>108607539
>>108608191
She will pin you to the ground and rape you and you won't be able to do anything about it but scream

>>108607447
Everyone 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 software

That’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
>>108607822
Agree 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.

>>108608313
Man, 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

>>108608313
so do TDD if you want people to hate you, got it

>>108608385
This 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.

>>108607467
Tats and a lack of tits.
Patty needs a boob job.

>>108608732
That’s your take-away? You get invited to many parties?

>>108607447
TDD 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.

>>108608764
You 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.

>>108609204
No, but also people at work don't hate me.

>>108607447
TDD 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 pass
people that rely on tests like "once the tests pass it's all good" are a problem

>>108607447
TDD isn't a meme
TDD helps you write code that is PERFECT
TDD 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.

>>108609567
this has to be bait

>>108609238
TDD 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.

>>108609707
Lmao

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.

>>108607447
testing is a meme

>>108607447
she is so fucking mid.

>>108610474
TDD 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.

>>108607447
Testing in general is a meme. I just write code that works. Not sure why so many people have trouble with that.

File: no-country-for-old-man-awkward.gif (441.9 KB)

441.9 KB GIF

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.

File: QR Code 9913d927-da78-48e7-b68d-ed1441cc7c02.png (5.8 KB)

5.8 KB PNG

>>108607447
Cure.

File: nose.png (80.5 KB)

80.5 KB PNG

>>108607447
i want to put my nose right there

>>108607447
This 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.

>>108607447
idk, 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 code

maybe 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 meme
i'd always learned that this was literally what TDD meant, not that just having tests is TDD by default

>>108607475
Yes, but when making related changes, it shouldn't break existing features. It also allows you to refactor your code.
>>108612602
I 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.

>>108612647
You're responding to a chatgpt post, bro.

>>108607447
Sort 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.)

>>108607447
is 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.

File: l-intro-1666665301.jpg (282 KB)

282 KB JPG

>>108612723
you don't think I could tell?

>>108612738
https://lewiscampbell.tech/blog/260414.html
clanker 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.

>>108607447
Tests? 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 interface
Not 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.

>>108612893
there are a great number of cases where this doesn't work in practice
I refuse to elaborate