Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
monkeyboy85573dYep. Your organization will happily create a whole new siamese twin set of code. Equally as big as the actual application code. Chock full of cases that will never exist in the real world. More tightly coupled to the application code than a couple of horny 17 year olds. This "test" code will make future changes cost multiples what they did before. And yet, management will equate the existence of that "test" code" with quality. When it turns out the software is still crap, they will blame the developers for not writing good enough tests and demand 110% test coverage for the next release.
Hackshay41473dAlso Unit Testing
7Raiden100872d@monkeyboy Well, one thing is tdd the other is writing sensible tests. I can't truly trust my code if I don't have unit tests that covers the most reasonable scenarios. When something breaks I know where to start looking :)
It's not always like that, when it's not I just write another test that covers this failure :)
monkeyboy85572d@7Raiden You have hit upon the most important facet of unit or automation testing when you say you know where to look when something goes wrong. Testing does not provide quality. It provides a level of change notification. That's all. The code can be awesome or crap regardless of test coverage. So, as with any effort, the question asked about testing shouldn't be about test coverage, it should be about whether it's worth the cost.
devnulli23472d@monkeyboy yeh, writing tests suck,
but it depends on what applications you write. when its about long (years, decades) living applications, you are not right. its a good thing for a company, its a good thing for costs.
if you have the feeling that tests are a waste of money/time then, imho, you
- dont write sensible tests or
- develop applications where its not about quality (short living, low risk)
AND you must always keep in mind, that the meme is wrong: you dont write the test to confirm that what you just coded earlier works, but to ensure no one breaks it while fixing something somewhere else in the code, maybe years after you wrote that, maybe not even knowing your code exists
arekxv91272dEven though it sounds counterintuitive, writing tests actually makes you go faster. Why? Because imagine yourself in a following scenario.
You wrote a project for 2 months with no tests which handles single payments. Everything works, client is happy all that. 2 years pass and they want to add recurring payments to the mix. You do NOT remember all of the code. You know you wrote it, its clean and all, but you cannot for the life of you remember all of the small rules and gotchas you encountered. What does that make you? Reaaaaally slowly add, triple check everything, go re-read all of the old code, refactor it then triple check everything again...
Now imagine you covered it all with tests? You just code, then run tests, fix stuff, run tests and you are done (with new tests for the next time).
Imagine how safe and secure that feels? Now thats the "speed" the tests offer.
@oreru the error sensors in cars an planes also arent' YAGNI and KISS
i would not prefer to fit those AFTER something crashed
@oreru thats right, for smartphone apps i would agree with you.
Even with all of the YAGNI and KISS principles you employ you cannot do a multi-module complex project and keep track of everything all of the time, especially when working on a team. And would you rather cost clients a lot more money in damage repairs and lawsuits than just spend a bit more extra on few tests to help everybody catch bugs early and be safe?
there are many nice inputs in that paper. especially the "throw away tests that never fail" thing, i like it
make sure you dont interpret this as making yourself a nice "test ice cream cone", it a well known anti pattern
Your Job Suck?
Take a quick quiz from Triplebyte to skip the job search hassles and jump to final interviews at hot tech firms
Get a Better Job