9

I have a java class hierarchy that are formed by an Abstract class and N extensions of it. In the abstract class I have a method that is annotated with a @Remove annotation. While we won't get any exceptions of won't fail fast if this annotation is removed, we may get out of memory exceptions, so I would like to be sure that we notice as fast as possible if this annotation disappears in some refactoring.

I am trying to create GUTS (good unit tests), so I thought I could document this "technical requirement" in my tests, with a test case that states it.

But this is not a feature, it as an implementation detail and it is not linked to the behavior of the method (the method could be empty, but it has to exist and has to be annotated).

Is it ok to create a test for that or is there any other way to check the existence of this annotation?

Improve this question
1
  • 1
    Are you asking how to do it, or whether doing it is good software engineering practice? The answer to the latter is yes. Tests verify the quality of your code base; they don't necessarily check current behaviour. It's perfectly fine to have tests that verify conditions intended to foster future good behaviour. – Kilian Foth Oct 26 '15 at 12:53
5

Yes create a unit test. You are saying that if the annotation is removed then you can get out of memory bugs in production. That would be a killer bug. Letting that happen due to some idea that tests should somehow be limited is counter productive. Tests should check for correctness in all senses. The sooner you detect the possible problem the better so having a unit test and failing the CI build is the solid way to prevent the bug. Trying to invent another mechanism to prevent the introduction of such a bug does not seem worth while. Every new developer will have to be given an explanation of how to handle the "special case" of none functional correctness tests. That is most likely not a good use of developer time.

Edit Teams that do BDD are likely to separate out business functional test from technical tests such as performance tests. Typically teams have different types of tests including integration tests that are run less frequently than their core business logic tests. This is usually done with build profiles so that developers in their flow can run fast business logic tests frequently and the slower integration tests before they commit code. The CI build will run all the tests.

Improve this answer
2

When a critical function is implemented using a declarative technique like this, I tend to prefer using an integration test that includes the part of the framework that recognises the declaration. This protects you from changes in the frameworks behaviour, misunderstandings of the effect of the declaration, and so on. Simply testing the presence of the annotation does not guarantee any specific behaviour.

Improve this answer
3
  • Hi! This is interesting, how would you check the behavior of the @remove annotation, for instance? – JSBach Oct 27 '15 at 8:17
  • Unfortunately, I'm not familiar enough with EJB to answer this - I tend to avoid working with the technology precisely because I find it difficult to write good tests for. – Jules Oct 28 '15 at 10:03
  • The idea of this annotation is that it tells the container that the bean could be removed. It is unfortunately hard to test this behavior :( – JSBach Oct 28 '15 at 10:27

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.