Best strategy to test automatically a web application

Question

I have an application that consist of a web server in Java EE (EJBs and JAX-RS RESTful services) and a client module in Angular that runs in a browser.

The components that I can unit test automatically are:

1. Java EE presentation layer (RESTful services)
2. Java EE business logic (EJBs)
3. Java EE data access layer (DAOs)
4. Angular javascript layer
5. Common javascript functions

In addition to that, I could test a Java EE Restful service end-to-end, with or without mocking objects. And lastly, a browser end-to-end test.

The Java tests are done with jUnit/Mockito and the Angular tests with Karma.

Question: if I unit test each of the Java classes (points 1, 2 & 3) and later the Java EE Restful end-to-end (without the browser), wouldn't I be testing the same thing twice?

On top of that, I could test Java EJBs starting an application server context (with Arquillian) or without starting the context (mocking with with Mockito).

Since writing tests takes time, I'm trying to find the best way to test the software without overlapping. What would be the best strategies? Where I should mock objects and where I should not?

Answer 1

There will always be some overlap in different tests, but if you look at the test pyramid the different layers have different goals.

The test pyramid is a way of thinking about different kinds of automated tests should be used to create a balanced portfolio. Its essential point is that you should have many more low-level UnitTests than high level BroadStackTests running through a GUI.

https://martinfowler.com/bliki/TestPyramid.html

• UI: Does a feature work end-to-end (no mocks)
• Service: Does the wiring work between components/services (maybe some mocking)
• Unit: Do individual components work (more mocking)

The challenge is indeed how to make the least ammount of tests in each layer, how to keep the whole test-suite lean and mean. Test suites should run fast, because you want to rigorously refactor continuously.

• Code coverage can help as it gives insights how often a line of code is touched by a test.
• Mutation testing can help to find which lines of code do not have enough tests.

I think the topic is complex and the answer greatly depends on the context. I hope my answer helps to give you some perspective to start your journey.

Here are some other reads with different views:

• Programmer Test Principles (Kent Beck). Challenge your different tests and see if they meet these princibles.
• Why the Testing Pyramid is Misleading. Don't forget the right risk balance, depends on your context
• Mocking is a code smell
• Testing pyramid in a nutshell

Answer 2

I have been in similar situation in my qa services project. API are being developed, (also getting updated frequently) and UI does not exist and we are doing a minor release based on API testing.

1. We need to draft E2E flow cases. (high level not very formal)
2. Running the API end to end flow test is always useful. Ultimately we want the E2E flow to behave correctly. It also covers the unit tests
3. If there are any issues in E2E flow, we can identify the failing API and update the unit test for it. This approach worked for us.