Integration test with @ManyToOne entities

[raul.arabaolaza]

Hi,

Taking my first steps in Roo, great project by any means I can think, I have some unexpected behaviour when creating integration test when using composition in my entities.

I´ve two entities, the have a composition relantionship created using the add field reference jpa command.

@Entity
@RooEntity
@RooJavaBean
@RooToString
@RooPlural("Entradas")
public class Entrada {

    @NotNull
    private Double cantidad;

    @NotNull
    @ManyToOne
    @JoinColumn
    private Producto producto;
}

@Entity
@RooEntity
@RooJavaBean
@RooToString
@RooPlural("Productos")
public class Producto {

    ...
}

When I create integration test for them using Roo the ProductoIntegrationTest fails due to integrity constraint violation in testRemove.

It´s easy to manually fix this, either modifiying the remove method or the testRemove method, but I think it should be a way to customize the test´s behaviour in this context because I believe a integrity constraint violation exception could be the expected behaviour when trying to delete a Product in some use cases. Or in general is usefull to test that some expected errors or exceptions occur.

What do you people think??

Best Regards, Raúl

[Stefan Schmidt]

Hi Raul,

Thanks for making this suggestion. Do you have a specific way in mind on how to extend the current test generation add-on to cater for this case? You can always create a Jira 'improvement' ticket and we are happy to review your suggestions.

What is currently possible is that you can simply push-in the test method you wish to customize and therefore Roo would not overwrite your custom test (use the new STS feature or do it by hand). This is probably the most feasible solution as opposed to creating extensions to the test commands in the shell to cater for such 'special' cases.

What do you think? Again, if you think it can be done better than that we are open for suggestions .

Regards,
Stefan

[raul.arabaolaza]

Hi Stefan,

As allways thanks for the quick answer , I´ve one suggestion to customize test generation, one that not involves modifiying the shell command.
I think the point is to make the test generation aware of some extra metadata, so i suggest creating a new test customization annotation, some in the form

@RooTest[testMethodName], for example @RooTestOnRemove.

This annotation could have class target and have attributes like exceptionExpected="MyException" or testNullParameters=true to further customize the test generation.

It´s a very basic idea for the moment and i know it´s a very unusual use case so i don´t know if it´s worth the work.

Do you think this idea have some sense? If so i could open the Jira ticket or maybe try to implement it.

Best Regards, Raúl

[Stefan Schmidt]

Hi Raul,

Thanks for your suggestions!

I am not quite clear who would add this new annotation to the test source code, Roo (during test case generation), or the developer?

If you have Roo in mind you would need to extend the commands for all sorts 'special' cases that could occur in your tests.

If you have the developer in mind, that would mean the developer wants to customize his tests for a given scenario. In this case we would highly recommend to 'push-in' the test code from the aspect to the test java source (so that Roo won't overwrite the tests any more). Considering your @RooTestOnRemove idea, I believe this is already entirely possible to do with standard JUnit. What functionality / benefit would this new Roo annotation add?

Regards,
Stefan

[raul.arabaolaza]

Hi Stefan,

Thanks for your time in reviewing my idea, let me first answer your cuestions and later explain the scenario i have in mind.

As you suggest i have in mind that the developer wants to customize the test case scenario using the annotation in the entity class, Roo´s test addon will use this annotation to gain further information about the test to generate.

My scenario:

In more than half of the applications i need to develop there´re composition into the model, just like the example in my first post, when i persist that relationship with JPA i usually use the join table strategy just like Roo generates. In this scenario a DataViolationException is the expected (and desired) outcome when triying to remove some entities, it´s defensive programming but because where´re many people in diferent teams working we need that level of paranoia.

Also it´s part of our test policy to try wrong parameters (wrong ids, nulls, and so on) on our test to be sure that errors are properly managed.

For me this is a standard test policy but i have allways work in the same company/group, so my experience can not be trusted. Do you think this scenario is a usual one???

So in my scenario, the default generated roo´s test fail out of the box and we will have to customize it more than half the time we use it. As you say, it´s very easy to customize this test to fit any special use case we can have pushing it into the java code (kudos to the AJDT´s team for that feature), but this way Roo´s test generation facilities are not helping us at all.

I belive that Roo´s test generation facilities are a way to promote and facilitate TDD but in my opinion without some degree of control in the test generation it will be very dificult to fullfil that purpouse because you will have tests that will need customization more times that is desirable. By allowing the developer to customize Roo´s test generation capabilities to fit more than the very basic model scenario i belive Roo´s tests, and Roo itself, could gain several usability points. Note that Roo already offers some sort of customization in the test generation with the remove, flush, etc atributes in the RooTest annotation. What i propose it´s to expand this customization options.

All of this is, of course, based in my experience, which can be not representative

Best Regards, Raúl.

[Stefan Schmidt]

Hi Raul,

I think your arguments are very good. I'd like to discuss this further with my coleagues but I think we can make the test case generation a little more flexible. Can you please open a Jira ticket for this so we can track the progress better (http://jira.springframework.org/browse/ROO)?

Thanks again for your suggestions here .

Regards,
Stefan

[raul.arabaolaza]

Hi Stefan,

Thanks for your kind words, the jira ticket is here: http://jira.springframework.org/browse/ROO-132 i´ve added also my sugestion for the use of annotations to customize the generated tests, but the main goal of the ticket is to make test generation more flexible anyway this flexibility is implemented.

This is my first Jira ticket for the spring framework, so feel free to correct or edit it anyway you think is needed .

Thanks again,
Raúl

[MiB]

I voted for this as I feel test generation currently needs some improving.