How has test driven development helped you in your programming career

How has test driven development helped you in your programming career

Other urls found in this thread:

akaptur.com/blog/2013/07/24/systematic-debugging/
twitter.com/SFWRedditGifs

you can't test what you can't catch farmboy

how has bait driven posting helped you

t. Torvalds

TDD is a meme that is being pushed too far. You start writing your code around tests, which means introducing all sorts of modern patterns such as dependency injection which in turn make your code more complex (inb4 but we might change in the future). Then if you didn't waste enough time already, you design mock classes and other bullshit. Think and analyze is a better approach, TDD is for pajeets.

TDD works fine as long as you're casual about it. If you go all culty you'll get nothing done. At the point you're even bothering to call it "test-driven development" you're dangerously close to being unproductive.

TDD is an outdated model. Using test cases as a specification is a good idea, but nobody can read unit tests, especially when they're well written and DRY. A much better model is Behavior-Driven Development (BDD) which takes the same concept but includes the all stakeholders as responsible for reading and understanding the test cases.

TDD is a waste of time. All you need is a valid schema

Logo-driven development is where it's at these days, OP.

Joke aside, testing is good, but full-on TDD only works when you have an exact set of specifications you can test against, not when you are treading new ground where you aren't yet sure how the application is even supposed to work. Another problem is that if you are trying to accomplish something that requires a non-trivial testing setup you are then faced with the question of who tests the tests.

wew, that sounds like some faggotry. I bet if I checked wikipedia the page would mention agile.

Haha, of course it's agile! Have you ever been a part of a large development team?

Team size is not an argument. Linux is one of largest software projects in existence and it's development is not based on BDD or agile or . I'm not arguing that BDD is necessarily bad, but it's not the only way to manage large software project.

And I would not argue that agile is appropriate for the Linux kernel development. What's your point? Seems you forgot to make an argument. Maybe you should suck Linus' dick, a man who can't even write his own compiler?

What I mean is, a large, multidisciplinary team. Linux kernel dev team are all programmers, so that is really not comparable to a typical piece of commercial software with a frontend, designers, etc.

By asking this question you are indirectly implying that agile is a sort of a "requirement" for developing large software projects. Because your previous sentence was
is in the question that follows your argument in question form. With that question you are challenging the person who wrote post with bad opinions on agile development. I then responded to your post, stating that there are other ways of developing software, not just a way you implied by asking that question. I admit that there is some ambiguity in second part of my post as BDD != agile, but is somewhat connected with agile principles. I hate modern buzzword jargon. Maybe you should stop sucking boss' dick for a moment and try to realize what are you typing?

Maybe you should read my follow-up about inter-disciplinary teams.

what a bunch of pajeet-tier bullshit, just sit down and code your to do list for the day you cunts.

Agile is the crossfit of software.

What the fuck is fagoli doing at a farm? That fat fuck couldn't walk a mile to save his life.That looks so fucking similar to him too.

Also nice try n-s-yayyy-kun, your datamining isn't working.

what's about about agile meme development
like are you all autistic and can't face to face with someone?

It's pushed by kikes in colleges. It reduced effeciency overall and alienates programmers and encourages their boss to be idiots who don't know what the fuck they are doing.

Yeah I thought about it for a moment, it makes sense if your client is the one funding everything but half the time they don't know what the fuck they want, that's where a legal papers come in. It's also a fucking huge waste of time writing down stupid fucking documents and interviewing them, then getting them to review it, confirm or "wait a minute this ain't right", back to the drawing board and doing all this stupid shit.

akaptur.com/blog/2013/07/24/systematic-debugging/
The most effective and efficient form of testing is just plain fuzzing. How does that fit into TDD?

It's wasted my time

...

I'm continuously pushed towards the impression that a single digit percentage of the participants on this board actually write code for a living.

This is your problem now.

Do you have a testcase that catches this?

This thread.

Testers are NOT developers. The two do not cross over at all, and have totally different mindsets and approaches to everything they do. Asking a developer to write tests is like asking an engineer to make a UI. Just fucking no.

Legitimate testers are fucking incredible. They're the kinds of people finding 20 year old security flaw edge cases that nobody else in the entire office would have ever even considered or thought about. The developer thinks his shit all works, but the tester takes it and rips it to shreds and sends it back.

I am torn.

I had to maintain a 15k LOC of Pajeet tier Java codebase that I written in 6 months. Which is not that much, but still the codebase was nightmare to maintain, because I didn't have a single test (no time to write them).

If I did TDD maintaining would be a breeze since I wouldn't have to spend 2 hours every release just to test every possible thing that could go wrong, just to find out that 1 thing slipped through and I had to make a new release.

But TDD adds so much cancer to the codebase and extends the development time by huge margin. Is there any language that does testing the right way out of the box? Golang, rust? I am only familiar with Java ecosystem.

Testing is the proper way to do your work. The time it costs to design and write your tests on top of your code is the cost of developing reliable software. Suck it up.

First to get laid off.

Don't do unit tests. Do more full-scale tests (whatever you want to call them - functional, system, integration, etc.). Bang for the buck is WAY higher at identifying problems, but they take longer to investigate than unit test failures. But if you have that hooked to a CI system, usually the programmer that fucked up immediately knows what was wrong.
I built a test system for our networking product that boots the firmware in several instances via KVM, ties their interfaces together, sets up a virtual network, then does iperf across them. It's a simple test but it stresses a huge amount of the product and it catches 90% of fuckups all by itself.

End to end test, that's what you're thinking of. Test actual real product functionality and features, rather than

Yeah. I think those micro tests they teach you to do aren't even remotely worth the time. I try to cover as much as I can per test instead.

So with what do you write these tests? Do you make use of tools like Ansible?

In my case, everything's custom built as it's not an easy thing to get an off the shelf tool for. Think of something kinda like GNS3 but focused on automated testing. But firing them off could be added to jenkins or something. Right now, I just have it email a mailinglist if something goes wrong.

AHHAHAHAHAHAHAHAHAHAHHAHAHAHAHHAHAHAH


HAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

SPARK, a subset of Ada.

...