Is TDD bullshit?

I understand the importance of unit tests, but I think it's fucking bullshit to begin the development of a feature with the unit test itself.
I always write the tests after the feature's code has been written, and I don't give a fuck

Attached: 5ryscmqtvkgmbh6ihg3k.gif (489x511, 14.75K)

Other urls found in this thread:

youtube.com/watch?v=pW-SOdj4Kkk
twitter.com/NSFWRedditGif

I see no value in unit tests. It's essentially writing the same code a few times - if this returns null, return somethinig - if not, return something else.
Only retards believe that unit tests save you from making bugs.

The only useful thing about unit tests is that they can be used as documentation to your code

And this is why offshoring doesn't work. Turd world software engineers are just too fucking incompetent.

It’s a tool to force you to contemplate input and output, to define your API. Ultimately, it’s a meme fad - if you can’t design APIs for shit you’ll design a shit API with or without tests first.

>begin the development of a feature with the unit test itself.
it assumes you know exactly what you're doing and have reverse engineered the process to build the feature and which functions/classes you require and what the ins and out of each of them are.
Of course if you have no plan at all then it won't work pic related it's me in 2 years

Attached: 1661032274947154m.jpg (923x1024, 98.96K)

>unit tests save you from making bugs
It's for easier maintenance that is to be able to debug/locate the problem quicker. It doesn't necessarily reduce the number of bugs just makes everything more maintainable

pretty much this

It's as big a load of shit as continuous deployment, agile, extreme programming, etc.
All this bullshit is why I'm now a farmer rather than a programmer.
They all have their place, but midwits drink the kool aid and think they're all silver bullets.

>pic related it's me in 2 years
yeah, but only the hairline. You will be an europoor forever

It's valuable as long as you're using soey technology. The only tests you would ever need with something like C would be regression tests, which you write once for the whole lifetime of the project.

Attached: file.png (639x724, 322.03K)

> How to tell everyone you are a 3rd rate FE developer, without saying you are a 3rd rate FE developer

Now, TDD is a high cost higher reward strategy. It has shit ton of requirements in terms of team members to produce good results. If used correctly it's a great delivery/stability boost. If you apply it badly it will be just a bottleneck with no real gain. Most teams fail to implement it big time. It's like Communism, but costlier and actually working.

I only bother writing end to end tests and regression tests.
TDD only makes sense if all of your interfaces are specced out and won't need to change, which is basically never the case in software engineering.
Good testing is important if you need comprehensive verification and the spec is fixed (ie implementing standardized cryptography)

>It's like Communism, but costlier and actually working.
that's the most awful analogy I have ever seen. Please kill yourself

Unit tests are cringe.
Based solution is integration tests + asserts everywhere.

How is it possible that every non-American has a shit opinion on this subject. No wonder we won the space race, and I guess US Brain Draining the world is real. TDD is useful for disassociating personal cognitive bias in authoring the imperative logic jn your changeset. It’s like measuring twice and cutting once.

This. The low level tests account for what static typing was invented for.

Funny it is political but only programmers will understand.

This must be a bot thread or a fishing thread for bots. Why would so discuss unit tests on Any Forums and not Any Forums?

Why not? Clearly these responses dissuade any decent author from worrying themselves about bots being written well enough to have any impact on the real world beyond reflecting it.

>Funny it is political but only programmers will understand.
I used to be completely against K&R bracing and tabs, but now I'm totally onboard.
I'm transwhitespace

The value is that when a Jew changes your code and the unit tests fail, they catch the Jew sabotaging your work before it gets into production.

Also, if your Jew manager wants you to change a feature, the unit tests will warn you about how you may have made breaking changes.

TDD is dumb for complex things
you end up rewriting all the tests anytime anything changes

better to write the changes at the end when you're comfortable the final design is fully functional and need to lock in functionality and correctness

>It's for easier maintenance that is to be able to debug/locate the problem quicker
lmao at one place I worked, they didn't want any accompanying comments to explain what code was supposed to do
so anyone coming after only knows what the code currently does and nothing else, they can never know if the code is actually doing the right thing

and they didn't want any diagnostic functions that let you quickly diagnose an execution path if something went wrong
good fucking luck to them, if they designed trains, they'd never be able to fix any problems cause they plastered over all the control panels

it doesn't surprise me that tech has become a huge pile of shit in the last 20 years
I don't see things getting better
youtube.com/watch?v=pW-SOdj4Kkk

>the hairline
lmao mean

>write tests like uncle bob tells you to, line by line
>suddenly have to redesign how the logic works because the problem wasn't clear at first
>have to rewrite the code AND all the tests

Integration tests are much better.
If they're too slow, your program is too slow and you need to make it faster.

Also, if you're just mocking everything and re-implementing the code twice to test it, what the fuck are you really testing?

>Based solution is integration tests + asserts everywhere.
that's ok, but integration tests rarely test all parts of the codebase, it's impossible to test all scenarios, it's more like testing the glue, rather than the bits you glued together

unit tests are fine for testing the correctness and limits of functions, but they should be written after

TDD is only ok if you know exactly what you're designing, which is dumb if you're prototyping something for someone who changes their mind all the time requiring huge architectural changes

It depends on what you're making, but very often it's absolutely great. If you're making something new, and you don't know what you're making yet or how it's going to be structured, then it's not necessarily the best choice.

However, if you're working with an existing program, adding or changing behavior, accept no substitutes than TDD/BDD. Write the test, put down what you expect it to do, and start implementing.
Hell I might even write the entire test class before I start implementing.