Announcement Announcement Module
Collapse
No announcement yet.
Integration test with @ManyToOne entities Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Integration test with @ManyToOne entities

    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.

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

    Code:
    @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.

    Its 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 tests 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, Ral
    Last edited by raul.arabaolaza; Jul 2nd, 2009, 07:52 AM. Reason: Fixed code tags

  • #2
    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

    Comment


    • #3
      Hi Stefan,

      As allways thanks for the quick answer , Ive 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.

      Its a very basic idea for the moment and i know its a very unusual use case so i dont know if its 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, Ral

      Comment


      • #4
        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

        Comment


        • #5
          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, Roos 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 therere 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, its defensive programming but because wherere many people in diferent teams working we need that level of paranoia.

          Also its 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 roos test fail out of the box and we will have to customize it more than half the time we use it. As you say, its very easy to customize this test to fit any special use case we can have pushing it into the java code (kudos to the AJDTs team for that feature), but this way Roos test generation facilities are not helping us at all.

          I belive that Roos 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 Roos test generation capabilities to fit more than the very basic model scenario i belive Roos 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 its to expand this customization options.

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

          Best Regards, Ral.
          Last edited by raul.arabaolaza; Jul 7th, 2009, 08:23 AM.

          Comment


          • #6
            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

            Comment


            • #7
              Hi Stefan,

              Thanks for your kind words, the jira ticket is here: http://jira.springframework.org/browse/ROO-132 ive 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,
              Ral
              Last edited by raul.arabaolaza; Jul 7th, 2009, 12:42 PM.

              Comment


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

                Comment

                Working...
                X