Best strategy to test automatically a web application



  • 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?



  • 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:



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2