This is what I heard today from one of the senior developers. His philosophy is that people who want tests just don't want to think. They don't want to invest time into understanding what the code is supposed to do and how their changes will affect everything. They are lazy coders who think that testing will solve all their problems.
I completely disagree (except the part about testing not solving all problems). I've been trying to push some testing culture forward in our company and did some for my parts as much as time allows. But it is hard when the software is not designed to be testable. It is also hard when you don't get support from your seniors and when time spent on tests is seen as wasted money.
Hearing this is discouraging.
What would say or do in this situation? Do you think testing is for lazy developers? Does your company have testing culture?
Latest comments (34)
I just wanted to explore an alternate explanation.
Most people (in the comments) are assuming that your senior is wrong and that may well be true. But the opportunity I see is for you to dig deeper with your senior and find out why he/she believes what he/she believes.
One of the "7 Habits of highly effective people" is "seek first to understand, then be understood".
By digging deeper, you might learn something valuable even if you don't agree with his/her position on testing. At the very least you might learn what kind of argument or proof would convince your senior to give unit testing a try (or to let you try it).
The funny thing is that in the following weeks he proudly announced covering an important part of application with unit-tests.
I guess the point was mainly about how important it is to think carefully about your design decisions and the changes you make to the code base. And that 100% coverage is a waste of time. With both points I agree. Maybe the rest was actually a joke. :)
Interesting. Now I'm even more curious to know exactly what he meant originally.
Do you think you'll ask about it or let it go?
I think I will leave it to be a mystery :)
I'd rather be in a team full of "average" developers who write tests than a minefield codebase with no automation which only geniuses can maintain.
I thoroughly believe that testing actually helps you think about the problem. That being said, I don't think you need 100% coverage either. Automated test suites give you a "warm fuzzy feeling" that given certain inputs, you get expected outputs. It also helps you see if there are any edge cases that you haven't thought about. To counter his point, I've encountered many people who haven't wanted to test because they're too proud of their code, too lazy to learn how to do proper testing, or can't do it "because their architecture isn't set up for it" (aka, it's bad architecture).
Having someone specialized doing the tests is something completely different. Their experience tells them where to search for bugs and so on. Sometimes testers in our company find bugs we had no idea were possible.
Requirements, unittesting and clear code go hand in hand.
I think your senior collegea overestimates him(sounds like typical male behaviour)self. How does he do heavy refactoring? Confirming that nothing broke by testing all use cases in his head?
Testing is good for three things:
I suggest you read / watch the following:
Unit testing: How to get your team started
https://www.youtube.com/watch?v=TWBDa5dqrl8&t=788s
Top Five (Wrong) Reasons You Don’t Have Testers
joelonsoftware.com/2000/04/30/top-...
The Hidden Costs of Neglecting Testing (shameless self-plug)
powerslacker.cc/hidden-cost-neglec...
Testing both automated and manual can reduce significantly reduce defects in software. This senior developer is just plain wrong. Which is OK, and presents an opportunity for you to educate them.
Google, Amazon, Facebook, and every major software company write tests, employ QA departments, and automate as much as they can.
Thank you for the resources, I will check them out!
I am a beginner with testing but I can see the potential benefits. Although I understand it can take a lot of time in the beginning and a shift in thinking about code and development. Habits are difficult to break and create.
Ew, I really don't like that dudes opinion. lol
He sounds like a grump.
He is actually a very nice and fun person and a great boss. :D
He tests in secret then ; ) jk jk lol
Testing adds information about risk. A system considered untestable is high risk. Initially adding levels of testing to a project may seem like a waste but this is a type of insurance that may pay off greatly in the future. Compared to a great future failure tests provide us with a much less expensive early warning that our system may not safe. Start small and begin to provide information and over time and compare scary systems with safe systems and capitalize on those successes.
To the question regarding testing; Testing is part of Craftsmanship, Craftsmanship is a trait of Professionalism, Professionalism is a property of Responsibility. Responsibility is invaluable within a high performing organization.
Two; Speak the Seniors language. Figure out what is important them, and how testing makes it even better. For example exemplify cases wherein testing has captured errors early (and cheaply) vs later and more expensive (in production). Or how testing is a cornerstone of high performing engineering departments.
At the end of the day businesses exists to make profit. If the Senior does not appreciate cost savings, and no one above them will champion the initiative, you choice is binary: change your boss or change your job.
The choice is even unary. I cannot change my boss unless I change my job, the company is too small.
But first I am going to try and make some difference. It is a challenge now!
If I understood correctly those developers are complaining that other people wants to make their work easier and safer by using proper tools to do that... I would say that deciding not to use a tool that can make our lives easier seems like a very bad choice, no matter how you look at it.
And yes, of course, tests can be taken too far and become an obstacle, but same thing can be said about almost any tool at hand: types, IDEs, dependencies...
Maybe they believe that it is possible to write perfect code that will never break...
I know someone like this; will not work with them again.
Could be... From my point of view the safest believe you can have as a developer is that everything is broken or is going to be broken at some point.
No mater how much experience you might have, how easy the problem to solve is or which tools you use. I guess that's because we engineer solutions based on trade offs and we always leave little things behind. Maybe it is because we don't always fully understand the problems we solve...