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 wan...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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...
Enter the room shouting "regressions, regressions, regressions" and see what happens 😬
Seriously speaking I think he's wrong saying that, but he might have been bitten by TDD crazies in the past.
What about introducing some chaos in the system by reproducible tests? Or doing integration testing? I feel like he mostly meant unit tests, where I'm sure he could be more reasonable with overall tests that you could break with a change as a demo. To demonstrate the point about regressions ✌🏾
I am trying to get to the point where my tests actually help as much as it is worth a demo with an "I told you" subtext. 😬It is a huge mess of legacy code at the moment that I am dealing with.
So far Cypress E2E is the most helpful tool to catch regressions, but even for that I had to push a few changes because certain things were incompatible or made tests too slow to write and run..
It's going to be a long and winding road.
Legacy code is a boon for tests shine though, I'm sure you'll prove their worth!
Thank you! :)
But I also will need to do these things quietly and as part of whatever I am supposed to do. Apparently, it is not appreciated to log hours just for "automated testing".
I will need to be Piter Parker.
From great power comes great responsibility 😜
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.
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 :)
It's about degree and amount of test.
For example of web programming, my solution is unit test includes usecase and entity, not test controller and db. This will be more quick and reduce amount of tests.
If need , add a short time to do integration test for page and db.
More test for key point such as domain model.
No a simple line for test, just experience.
I do agree that testing everything is unnecessary. But some testing, especially on things that, when broken, disrupt the client's workflow or experience, is hugely important.
It's about confidence for remove bug quickly and project control. Test is a valuable tool in the age, unless you are a superman.
And the confidence that the bug is actually removed and will not come back.
People definitely take test-driven-development to unhelpful extremes, yes. I recall a couple of developers who were obsessed with it, guilt-tripping others into 100% coverage (as if that were possible!).
In the days of ye olde Extreme Programming dogma, test-driven development supposedly gave license for developers to code in the most direct way possible to make the tests pass, which often resulted in some pretty awful code indeed. So that's an extreme.
Although, for a platform on which a business depends, TDD is pretty damn good.
Call me lazy, but I reserve my tests for bits of code that are really complex, like certain custom algorithms that can't be easily visually verified, and go easy on the bits that can be easily verified with a code inspection. My 2c!
I do agree that 100% coverage is too much and can be a time waste. In many cases even TDD is not suitable for the development process.
His point, however, was "no tests at all are needed if you think carefully when you code".
...and "lazy people are those who want tests"
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!
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).
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.
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?
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.
Yeah, the best approach is to pragmatically consider the problem at hand and do whatever works without being too dogmatic about it.
You don’t want to disrupt a roadmap towards the proper solution by demanding a certain approach.
Yes, I agree with this.
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