Are end-to-end tests better than unit tests in situations where they are applicable?

There is no correct answer (which is why Ive voted to close, as mostly opinion based). The best approach will be mostly situational and to some extent how you decide to define the unit. From your description of the problem domain, you have class A, calls class B, calls class C. You treat all classes as ones. This is one approach, but not the only one . You can view the module as a whole. If class A is part of the public interface for a module and classes B + C arent, then you have no reason to necessarily have tests specifically targeting classes B + C, as the available functionality would be tested through other classes that form the public interface. ...

The main problem with your first approach is its scalability. I'll demonstrate with very simple code (it's in C #, but I'm sure you can translate).

public class C {
    public int Method3(int cParam) {
        if (cParam > 0) {
            return cParam + 1;
        }
        else {
            return cParam - 1;
        }
    }
}

public class B {
    C _cInstance = new C();
    public int Method2(int bParam, int cParam) {
        if (bParam > 0) {
            return bParam + 1 * _cInstance.Method3(cParam);
        }
        else {
            return bParam - 1 * _cInstance.Method3(cParam);
        }
    }
}

public class A {
    B _bInstance = new B();
    public int Method1(int aParam, int bParam, int cParam) {
        if (aParam > 0) {
            return aParam + 1 * _bInstance.Method2(bParam, cParam);
        }
        else {
            return aParam - 1 * _bInstance.Method2(bParam, cParam);
        }
    }
}

      

        
        
        
      

    

To test all branches with class based unit testing, at least you have 2 branches to test in each class, so you have 2 + 2 + 2 = 6 test cases. If you go with Approach 1, testing all classes exhaustively, through class A, then instead of adding branches from each operation, you need to multiply it, so instead you have 2 * 2 * 2 = 8. Not much differences in this case, but if you did an extra check like MAX / MIN int for parameters and 0, you would test 5 scenarios for each value, which would give you a close to 15 versus 125 scenarios. The more differences / values ​​you have to test at your high level, the faster your test scripts multiply. Now consider the situation if an operation in class C is slow (say1 second). With option 2 it affects 2 tests, with option 1 it affects ALL 8 tests, the tests start to get painful. What happens if some of the requirements and class D change? It also uses class B and then class C. With option 1, you need to reassign all the different values ​​again to use class B + C. Youre essentially repeating tests for the same. Testing with option 1 is really starting to hurt now, running tests is very slow and without even considering hitting other external systems. With option 2, you knock out B and only test functionality D.and then class C. With option 1, you need to reassign all the different values ​​again to use class B + C. Youre essentially repeating tests for the same. Testing with option 1 is really starting to hurt now, running tests is very slow and without even considering hitting other external systems. With option 2, you knock out B and only test functionality D.and then class C. With option 1, you need to reassign all the different values ​​again to use class B + C. Youre essentially repeating tests for the same. Testing with option 1 is really starting to hurt now, running tests is very slow and without even considering hitting other external systems. With option 2, you knock out B and only test functionality D.

In my experience, if you go down route 1, you will probably create too many unnecessary tests that will make your test suite slow and / or you will start skipping scripts.

I need to rewrite option 2 as

Write unit tests that fully test each class or component. Write appropriate end-to-end tests to validate data flows through the system as expected. Do not try to completely check all possible inputs.

As Ive said, it might be wise for your specific scenario to consider classes A, B and C as a single unit / component. But if this is not the case, then testing individual classes individually helps control the number of scenarios that need to be tested, and therefore the amount of effort required to test thoroughly. It also helps to reduce the problem area that the person writing the tests has to do in their head. Its much easier to look at the branches in the class under test than it is to try to remember all possible branches in all the code that the class you are testing calls.

The reason Ive modified option 2 is because unit testing as a major issue does not mean you automatically reduce end-to-end testing to second grade, but they have different assignments. If you've been writing to a database, for example, you might have unit tests to verify that you are not trying to write strings longer than a certain value, and then do an integration test to verify that you can write strings that take that long. They work together, not in isolation.