In the TDD / XP circles I hang around in, sometimes the question comes up of why isn’t TDD more popular? If the practice helps us write better soft...
For further actions, you may consider blocking this person and/or reporting abuse
Sometimes is maybe because testing got appropriated by TDD, if you don't do TDD you're not testing, if you don't TDD you are worthless.
I don't like to write the test before the code, sometimes the whole structure of what I'm coding changes when I'm writing it so to make the same test over and over is awkward to me: maybe something in the current function started to look a lot like some other function I made and now I wasted time testing something twice or writing the code I realize it got some new condition to test that may invalidate the previously made test.
To me is annoying and I see no benefit from it, said that, to me, untested code is as unfinished as not running code, just because it compiles doesn't mean it does what it supposed to, so is not yet working code. Not even in my local repo I ever commit something not tested. Not tested is just a mockup and you don't mix mockup code with working and commited code.
Sadly TDD took over testing so people not liking TDD end up ditching and avoiding testing, why bother, if is not TDD is garbage anyway. It became a credo, something to blindly follow without question, and to attack anyone that don't follow the holy path. Almost like Agile, OOP or Robert Martin. Sacred words.
I did TDD once - properly. When I was building a cube library. It was a way to translate queries into MDX statements. I tried designing the application, like normal, and kept getting into knots. So I wrote it using TDD, and surprisingly with a bit of refactoring - the library was aweseome.
That was seven years ago and not for a client.
I only really write tests when working through logic or ideas. Very occasionally, if there are calculations or something which was hard to do and would benefit from a test for a developer in the future to view.
It is a strategic/team decision as to whether to have unit tests to help reduce regression fixes and completely agree it isn't something to undertake blindly.
Offtopic
It sounds like an euphemism, sorry I had to say it, I couldn't help it. :D
Could probably think of funnier euphemisms, but it works. :)
you probably could, but that one, is special, it wasn't planned, came directly from your heart. :]
and that is usually boring. :)
I like the idea ”not tested is just a mockup.” Similar to Michael Feathers’ definition of “legacy code.”
Testing is a whole bag of tricks and just the mention of TDD can turn someone away from testing entirely, which is unfortunate.
TDD is just a methodology, one of many, suited for some cases and not so much to others; some people feel comfortable with it and write better code because of it, others feel it awkward and cumbersome. TDD is not "the best". There are no recipe to write good code, just some guidelines and advices.
I think some aspects of TDD get too "personal", you can tell your employees what structure the code should have, deadlines, even format and style, but things like when to write the test, the order you make things, to me is too invasive, you are messing with the internal process of the programmer. Who cares if (s)he writes the test first or after, demand a proper test, trying to control the process is micromanaging and nobody appreciate that.
Hi Daniel. Gave you a heart, as it is probably a lonely existence being the judge,jury and executioner.
I think the honest reason why most development teams don't do unit testing, is because it is a big undertaking. Especially in enterprises. Code is simply additions to a platform, and testers, and users will pick up bugs during the SDLC. This sounds lazy - but my roles tends to be more data focused, and when working in development environments (not production...) or greenfield there isn't the data to assert the units.
As terrible as it sounds - you may not know if your applications behaves correctly until it is in Integration. Project teams have two decisions - create their own datasets for testing OR put it in integration and test in there.
I took a look at your sites and will bookmark this. Cheers.
Unit testing doesnt take the place of integration and e2e testing. Used together they become whole and eliminate the need for testers. It is the developers responsibility to check for failures through different tests in my company.
If you skip on unit tests, tests will run slower and be more brittle for the same test coverage
I like using TDD to organize my thought, build my business logic while evaluating the success of my code. It's more of a methodology.
I tried using it the first time when I was working on a project with a ton of technical debts (btw, I don't judge a codebase, if it doesn't create a big amount of problems, but if I must work 5 days instead of 1 on a bug because of the terrible written code, then sorry but yes I will have something to say about it) but I use TDD only when I feel it is necessary not just with the test coverage in mind. It's more of a way to clear my mind.
I have never done TDD, but I like to definitely write tests for all my business logic. I think with tests you can become confident, that you have covered at least those scenarios which you can think of.
But I think instead of developers becoming convinced to write tests, I think it's management who have to be convinced why we need tests, and how they add to overall project quality.
Thanks for this comment. I agree that people have different motivations and that TDD appeals to only a small proportion of people. Plus, there's often no incentive for devs to test--their performance isn’t linked to it, especially when companies have specialised test teams. Which all tallies with what you’re saying. What I disagree with is that testing can’t save time/money—while that’s certainly true for a lot of people, for many contractors/consultants testing becomes the reason why they are so highly valued in the community, because they can build maintainable, high-quality software that is built to last.
However I think the problem lies with the TDD/testing community on this one. We need to innovate. To find ways that everyone can be successful with testing and incentivize it enough that all devs want to do it, not just the ones that enjoy writing testable code.
Being able to take a TDD approach usually requires an idea of how to build testable code. Hell in some cases one might not have any idea what the code looks like at all, so testing it isn't possible.
At that point it just seems like an afterthought, and untestable code is one of the easiest ways to get some cheap tech debt.
Now getting around that sort of barrier is pretty hard since it requires more experience and discipline.
I use TDD for business logic, but convincing others to do it is difficult. I also find that continuing to do it as an example to coworkers is a good strategy.