/tech/ - Technology★

>>808863 (OP)

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

how has bait driven posting helped you

>There really are only two acceptable models of development: "think and analyze" or "years and years of testing on thousands of machines". Those two really do work.

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 <insert library here> 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

>>808863 (OP)

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.

>>809163

>A much better model is Behavior-Driven Development (BDD) which takes the same concept but includes the all stakeholders

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

>>809222

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

>>809224

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 <insert latest buzzword here>. I'm not arguing that BDD is necessarily bad, but it's not the only way to manage large software project.

>>809230

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?

>>809230

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.

>>809231

>Have you ever been a part of a large development team?

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

>Haha, of course it's agile!

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?

>>809249

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

>>809163

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

>standing up for meetings

>agile meme

Agile is the crossfit of software.

what's about about agile meme development

like are you all autistic and can't face to face with someone?

>>809536

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.

>>809538

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.

http://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.

>>810366

Do you have a testcase that catches this?

>>810700

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.

>>810883

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.

>>811051

>output is slow as fuck all because you spend 70% of your time writing and re-writing tests

First to get laid off.

>>810883

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.

>>811080

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

>did x method actually return an array?

>>811083

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.

>>811080

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

>>811167

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.

>>810883

>Is there any language that does testing the right way out of the box?

SPARK, a subset of Ada.