Announcement Announcement Module
No announcement yet.
roo produces wrong tests in inheritance of entities Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • roo produces wrong tests in inheritance of entities

    Hi there.

    I use STS-2.6.0-SR1 with Roo 1.1.3

    I defined one abstract entity A and I defined two entities B and C which inherit the A.

    While the tests produced by the definition of the B entity were correct, when I defined the C entity, roo produced tests where it tried to instantiate the A entity which is abstract.

    I deleted the C entity and defined it several times and always roo produced the wrong tests.

    It is supposed that I should not try to change the generated ITDs files produced and managed by roo.
    I tried to refactor the methods with the wrong code and push it into the java files (right click on a method-> refactor-> push in). The methods disappeared and I end up with no test methods for entity C.

    Any ideas?

  • #2
    I don't know how to fix the problem, that I have found too a lot of times. It's weird, but Roo randomly generates correct Test files (Roo_DataOnDemad and Roo_TestIntegration)

    Furthermore, Roo 1.1.3 never fails when I use it in debug mode. According to the source code, it returns always the correct name for the class that you want to create tests for.

    Regarding fixing your code, this is what I've done, that involves removing Roo for those files (DataOnDemand and IntegrationTest):
    1.- Quit Roo.
    2.- Fix the compilation errors. If necessary:
    2.1.- _Roo_DataOnDemand: substitute the abstract classes with the concrete classes to be tested. Use the standard that Roo uses (newTransientChildClass(), return ChildClass and so on)
    2.2.- Refactor -> Push in... the entire .aj (it's the easiest way). NOTE: if there is a compilation error, the "Push in..." only deletes from the .aj, but it doesn't create the code in the java file.
    2.3 and 2.4: repeat the process for the _Roo_IntegrationTest
    3.- Delete the @RooDataOnDemand and @RooIntegrationTest in the corresponding Java classes.
    4.- Open Roo shell again.
    4.1.- It will remove the _Roo_Configurable .aj files.

    It will work. At least there won't be compilation errors. Try "perform tests" in order to validate your code.

    I hope it helps you until the next release of Roo.


    • #3
      Roo only creates the DataOnDemand and TestIntegration .aj files if you have told it to with either the --testAutomatically attribute on the entity command or with the test integration command itself. Roo doesn't randomly create tests for you


      • #4
        roo produces wrong tests in inheritance of entities

        Thank you for your reply. It works.


        • #5
          That's right, thank you, Alan.

          What I meant was to correct the tests for a hierarchy of inheritance, when they have compilation errors, if you created them, either with the "--testAutomatically" or with the "integration tests".

          Of course, the tests are not created unless you tell Roo to do it.

          But if you ask Roo for it, an stage for testing is created, with java an aspectJ files. The latter could be incorrect and they needed to be pushed in the java classes. Before that, you need to correct them without the Roo shell active.

          Then, it's necessary to delete the Roo annotations from these test java classes, because Roo will try to re-create them the next time you open the Roo shell.

          Due to the embedded annotations, Roo will try to manage them with aspectJ files. Sometimes Roo creates the .aj files, sometimes compilation errors appear within the IDE (STS in my case)

          I apologize for the misunderstanding with the word "randomly", I think I didn't speak correctly.

          What sometimes happen in random is the correctness of the test classes and aspectj being created by Roo. I mean, sometimes Roo doesn't create the tests with failures, but sometimes it does.


          • #6
            It seems this problem has been solved with the new release of Roo: 1.1.4.

            At least it doesn't fail in my first example using 1.1.4.

            However, I'm not going to repeat the Roo commands with the 1.1.4 for the previous project, the one that I created with 1.1.3, because I modified it manually a lot, in order to make it works with the legacy database that it belongs to.

            To summarize: good job from the Roo development team.