Search code examples
javacassandralagom

What is the unit testing paradigm in the Lagom framework?

I am new to the Lagom world. I have a scenario to work with unit tests. I work under the Lagom / Java framework and a Cassandra database. I have two different services:

  • Device Service
  • User Service

My need is an intelligent access scenario. A user must register his device to have access authorization. This mechanism is managed by a WBS connect () in the device service. So this WBS deals with:

  • If the device is not available: it stores it in the DB (for security reasons) and does not allow access

  • If the device is registered: it records the date of the access and authorizes the access

My implementation is ready, it works fine. But my question is how to handle this in the unit test side. Especially for the autorized access scenario because for a test start, I do not have a device registered in my DB / persistence.

  • Do I need to invoke a WBS Add () that adds a device to my DB / persistence and then invoke the WBS connect () to simulate the access authorization?
  • Is there a solution to run the WBS connect () without relying on a DB?
  • If my WBS depends on another Service (User service), how to manage the unit test? Do I have to re-implement the User Service in the unit test of the device service?
Solution

  • Best I can tell, the Lagom team doesn't believe in traditional unit testing for services; however, there are some unit-style ways to approach testing Lagom services. This is traditionally how testing is prescribed on a "unit" level:

    • Domain object tests

      Testing external commands, events, and proxies

    • Persistent Entity tests

      Testing what happens when your persistent entity attempts to handle entity commands

    • Single service tests

      Tests that your service can handle happy/unhappy paths

    • Message broker tests

      Tests that your service publishes or receives kafka messages

    As you probably know, Lagom prescribes a Spring-style API/Impl bifurcation. As a consequence, domain objects tend to fall into the API tests and the others fall into Impl tests. This should make sense from a DDD standpoint.

    Without much imagination, you can probably see how extending the single service tests could span to multiple service tests or integration tests.