My app has a service layer which is composed by CDI @ApplicationScoped beans. This is a class extracted from my project:

public class PostService {
    @Inject private PostRepository postRepo;
    @Inject private UserRepository userRepo;
    @Inject private SectionRepository sectionRepo;
    @Inject private LoggedInUser loggedInUser;

    public PostDto getPost(@PostExists int id){
        Post p = postRepo.findById(id);
        //create post DTO from p
        return post;

    public void delete(@PostExists int id){

    public int newPost(@NotBlank @Max(255) String title,
                       @Max(2000) String body,
                       @SectionExists String sectionName){
        User user = userRepo.getByName(loggedInUser.getUsername());
        Section section = sectionRepo.getByName(sectionName);

        Post post = new Post();
        post.setContent(body == null || body.isBlank() ? "" : body);

        return postRepo.insert(post).getId();


PostService is a class that contains the business logic for the manipulation of the Post domain objects.

Many things are actually delegated to other classes:

  • Dependency injection by the @Inject annotations
  • Parameter validation by means of the Constraint validator annotations to define preconditions (Some validators may hit the database)
  • The @Transactional annotation decorates the method adding transaction boundaries
  • Authorization checking by means of @RolesAllowed

But with all these dependencies from external mechanisms, and with this few lines of code that actually hit my business logic, how can I test this class? Does it make sense to unit test this class, or should I go directly with integration testing with an embedded OpenEJB container? (I'm currently using TomEE)

I'd like to unit test my service classes, in order to maintain consistency on my API in terms of behaviour. However, not using an embedded EE container would mean ignoring some mechanisms that are actually applied in the "main" code. How should i proceed?

  • 1
    Run from tests that try to validate more than 1 thing, because they become complicated and are prone to become boiled-plate code over time. So, why not test the service with unit tests first and then implement E2E tests focused on validating transactionality and security? Ideally, you should have both.
    – Laiv
    Jan 18 at 15:49


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.