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.

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!

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.

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 ✌🏾

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...

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.

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.

Ew, I really don't like that dudes opinion. lol

He sounds like a grump.

Testing is good for three things:

1. Documenting code usage and functionality. Comments can lie. Tests cannot.
2. Ensuring basic use cases have been fulfilled and that unhappy paths cannot be fulfilled.
3. Preventing regressions. Once a defect has been found, that should be the last time that defect is found by humans. Computers are excellent at doing boring, repetitive work.

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.

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.

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.

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).