If things are hard to reason about in isolation, they are impossible to reason about as a system. Unit tests tell us at an atomic level what works and under what assumptions it works given a large number of fast running assumptions. System tests tell us that something doesn't work, somewhere based off a very narrow, slow running set of assumptions.
Anyone still arguing against unit tests is either a complete genius programmer or a dangerous developer. I've met very few genius level developers in my time...and they all prefer unit tests.
Based on your analogy, all successful projects delivered on time are either built by complete geniuses or fully covered by unit test cases. Well, in the past 20 years of my journey in insurance, corporate banking, supply chain, retail data science and so on about roughly 80% of projects didn’t bother too much about unit test cases and are highly successful. Fact is most of them are built by normal devs who know how to consciously write code. They don’t consider themselves as geniuses, including myself.
You can be a dangerous developer and deliver on time. "On time" isn't the only marker for Software. There's also quality. You can deliver utter tripe on time, every time then need to spend 60% of your time doing rework.
How do you know the developers in my team are dangerous? Fact of the matter is, none of them are dangerous. They are rather smart. We know how to get mileage with ITs, E2Es and regressions and shadow the need to write 1000s of useless unit tests. We delivered solid products and not just us. I have seen an entire generation do that. Quality can be achieved by different tactics. Anyone who is saying there is only one way to achieve quality is unfit.
I never said there was only one way to achieve quality. I said that by not unit testing, it is much harder to ensure quality. How do I know your developers are dangerous? I don't. I know that they can't possibly cover all testing scenarios in integration or end-to-end because that is an infinite number of tests for most applications. So either they understand the code and interactions so well that their base level and interaction assumptions are all correct most of the time or they are fooling themselves and they've been lucky. Writing proper unit and integration tests takes away that mental load and ensures that there are no assumptions that are waiting to be tested.
I agree on the fact that there has to be UTs to cover anything that has medium level complexity or higher in the codebase. But what I have seen in the recent years is devs are writing what we used to call as "checksum" test cases. They write test cases that test, for example, a function x() {} calls functions a() and then b() and then c() and assigns so and so value to a variable. What they are essentially doing is writing a hascode protection for x(){}. In this scenario, when another dev wants to refactor x() they have to rewrite the entire test case. So the problem here is, unit tests written are not testing the output of x(), rather they are forcing x() to be written in a specific way. Tests should focus on what, not how. Thats where unfortunately many projects are failing the overall goal. Even in our current system (6 years old), we have 25+ angular apps in a mono-repo and a whopping 10,000+ UI unit tests. We continue to see considerable amount of defects. When we finally ran a stat on how effective the existing UTs are, we found they only prevented about 8% of defects during development. If I were a business owner and spending so much money on testing, I would expect that % to be much higher. On the other hand, we found a solid reliability on our E2Es and ITs. E2Es and ITs are harder to write, but they provided us the best ROI so far.
A method which calls three others and assigns a value outside the unit which is just testing that value was set on a mock. The unit test is describing that the unit passed responsibility of assigning a value elsewhere. We just need to check the value is correct.
A method which calls three others and assigns an internal value which is a unit test that checks a unit has a certain value after x() is called. The unit test is describing that calling x() mutates the state of the unit.
A method which calls three others and returns a value which is a unit test to check the return value. The unit test is describing that a value is expected when this method is called.
In either of these you could run 1000 tests in a split second. You will never reach that kind of coverage on E2E and if you do it will cost you a hugely unreasonable time investment. All of these tests focus on aunit as a black box and therefore a What and not a How so not sure what your complaint on that front is.
It sounds like your E2Es are providing the best value because your units or your unit tests, likely both, are badly designed.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
If things are hard to reason about in isolation, they are impossible to reason about as a system. Unit tests tell us at an atomic level what works and under what assumptions it works given a large number of fast running assumptions. System tests tell us that something doesn't work, somewhere based off a very narrow, slow running set of assumptions.
Anyone still arguing against unit tests is either a complete genius programmer or a dangerous developer. I've met very few genius level developers in my time...and they all prefer unit tests.
Based on your analogy, all successful projects delivered on time are either built by complete geniuses or fully covered by unit test cases. Well, in the past 20 years of my journey in insurance, corporate banking, supply chain, retail data science and so on about roughly 80% of projects didn’t bother too much about unit test cases and are highly successful. Fact is most of them are built by normal devs who know how to consciously write code. They don’t consider themselves as geniuses, including myself.
You can be a dangerous developer and deliver on time. "On time" isn't the only marker for Software. There's also quality. You can deliver utter tripe on time, every time then need to spend 60% of your time doing rework.
How do you know the developers in my team are dangerous? Fact of the matter is, none of them are dangerous. They are rather smart. We know how to get mileage with ITs, E2Es and regressions and shadow the need to write 1000s of useless unit tests. We delivered solid products and not just us. I have seen an entire generation do that. Quality can be achieved by different tactics. Anyone who is saying there is only one way to achieve quality is unfit.
I never said there was only one way to achieve quality. I said that by not unit testing, it is much harder to ensure quality. How do I know your developers are dangerous? I don't. I know that they can't possibly cover all testing scenarios in integration or end-to-end because that is an infinite number of tests for most applications. So either they understand the code and interactions so well that their base level and interaction assumptions are all correct most of the time or they are fooling themselves and they've been lucky. Writing proper unit and integration tests takes away that mental load and ensures that there are no assumptions that are waiting to be tested.
I agree on the fact that there has to be UTs to cover anything that has medium level complexity or higher in the codebase. But what I have seen in the recent years is devs are writing what we used to call as "checksum" test cases. They write test cases that test, for example, a function x() {} calls functions a() and then b() and then c() and assigns so and so value to a variable. What they are essentially doing is writing a hascode protection for x(){}. In this scenario, when another dev wants to refactor x() they have to rewrite the entire test case. So the problem here is, unit tests written are not testing the output of x(), rather they are forcing x() to be written in a specific way. Tests should focus on what, not how. Thats where unfortunately many projects are failing the overall goal. Even in our current system (6 years old), we have 25+ angular apps in a mono-repo and a whopping 10,000+ UI unit tests. We continue to see considerable amount of defects. When we finally ran a stat on how effective the existing UTs are, we found they only prevented about 8% of defects during development. If I were a business owner and spending so much money on testing, I would expect that % to be much higher. On the other hand, we found a solid reliability on our E2Es and ITs. E2Es and ITs are harder to write, but they provided us the best ROI so far.
Your example isn't clear but either it's...
A method which calls three others and assigns a value outside the unit which is just testing that value was set on a mock. The unit test is describing that the unit passed responsibility of assigning a value elsewhere. We just need to check the value is correct.
A method which calls three others and assigns an internal value which is a unit test that checks a unit has a certain value after x() is called. The unit test is describing that calling x() mutates the state of the unit.
A method which calls three others and returns a value which is a unit test to check the return value. The unit test is describing that a value is expected when this method is called.
In either of these you could run 1000 tests in a split second. You will never reach that kind of coverage on E2E and if you do it will cost you a hugely unreasonable time investment. All of these tests focus on aunit as a black box and therefore a What and not a How so not sure what your complaint on that front is.
It sounds like your E2Es are providing the best value because your units or your unit tests, likely both, are badly designed.