In my experience, unit tests are crucial for pieces of code that can be tested as an independent unit. I believe as soon as you start to mock all sorts of dependencies in order to write a unit test, you are not testing the truth anymore.
With modern, a lot more reliable testing tools, I've seen huge benefits in writing more end-to-end tests and focus on unit tests only where it makes sense.
A single unit test covers a small area of the code whereas a single end-to-end test covers a larger area of the code and with that, has the potential to catch more bugs.
It takes time to set up a fully automated end-to-end test environment, but I've seen it worthwhile many times over the past few years.
Problem with end-to-end tests is that you can't easily test outliners because often you don't control all the ends. Covering all cases is many times hard or even impossible (you want to test what happens with your (micro)service if another service it depends on fails in a certain way)
Also, they are much more expensive.
In the end, both unit, end-to-end and integration testing need to coexist, but in my experience, having a solid unit tested base, can save you lots of trouble/code higher in the pyramid.
Also, you're right, when unit testing, you're not testing the whole system, you're testing the unit, the function or class and assume that if all units work, the system works as well. This assumption can be wrong, that's why integration, end-to-end and manual testing exists parallel.
Ultimately, for me, cost and time are the main reasons I fancy the unit tests first approach, although I agree it's also a matter of team/organization/project/tech stack etc
Well said. We follow a very similar strategy to produce an effective and yet defect free product that also meets the timelines. For really complex functions, especially the ones that have multiple permutations of inputs and outputs, we write unit tests. For example, lets say we have a complex math function that resolves inputs from 15 different sensors and produces > 10 different variations of outputs. Manual testing in this scenario is tedious and discouraged. For simple scenarios, we use ITs, E2Es and regression to cover a large area. Best of both worlds.
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.
In my experience, unit tests are crucial for pieces of code that can be tested as an independent unit. I believe as soon as you start to mock all sorts of dependencies in order to write a unit test, you are not testing the truth anymore.
With modern, a lot more reliable testing tools, I've seen huge benefits in writing more end-to-end tests and focus on unit tests only where it makes sense.
A single unit test covers a small area of the code whereas a single end-to-end test covers a larger area of the code and with that, has the potential to catch more bugs.
It takes time to set up a fully automated end-to-end test environment, but I've seen it worthwhile many times over the past few years.
To visualize my thoughts:
Diagram source: excalidraw.com/#json=5186401523990...
Problem with end-to-end tests is that you can't easily test outliners because often you don't control all the ends. Covering all cases is many times hard or even impossible (you want to test what happens with your (micro)service if another service it depends on fails in a certain way)
Also, they are much more expensive.
In the end, both unit, end-to-end and integration testing need to coexist, but in my experience, having a solid unit tested base, can save you lots of trouble/code higher in the pyramid.
Also, you're right, when unit testing, you're not testing the whole system, you're testing the unit, the function or class and assume that if all units work, the system works as well. This assumption can be wrong, that's why integration, end-to-end and manual testing exists parallel.
Ultimately, for me, cost and time are the main reasons I fancy the unit tests first approach, although I agree it's also a matter of team/organization/project/tech stack etc
Well said. We follow a very similar strategy to produce an effective and yet defect free product that also meets the timelines. For really complex functions, especially the ones that have multiple permutations of inputs and outputs, we write unit tests. For example, lets say we have a complex math function that resolves inputs from 15 different sensors and produces > 10 different variations of outputs. Manual testing in this scenario is tedious and discouraged. For simple scenarios, we use ITs, E2Es and regression to cover a large area. Best of both worlds.