Announcement Announcement Module
No announcement yet.
Repository layer and integration test Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Repository layer and integration test


    I'm trying to implement an integration test against an entity handled by JPA and a repository layer.

    I did a reverse engineering of a database schema and then created the repository for each entity.

    Creating the entities from a reversed engineered database schema:

    database reverse engineer --package ~.domain --schema PUBLIC --testAutomatically --activeRecord false
    Creating a repository for each entity of the schema:

    repository jpa --interface --entity
    Since the schema contains 117 tables I created an equal number of repositories with the repository jpa above command.

    Question 1: Is this the way to proceed to have a repository layer and avoid the active record pattern ?

    I then tried to create an integration test:

    	public void testSaveAndRetrieve() {
    		AddressDataOnDemand dod = new AddressDataOnDemand();
    		Address address = dod.getRandomAddress();
    Question 2: How to expose a reference to the repository in the integration test ?

    I could not find the answer in the Spring Roo reference manual nor in the Spring Roo In Action book.

  • #2
    Section 9.4.2 is your answer. Inject the repository using @Autowired, and make sure to make the tests @Transactional. Then you can use a @Before method (they are inside the transaction) to set up test data. Your transaction will automatically be rolled back.

    The generated Spring Roo integration tests are useful if only to get you a test context, and to test the crud. If you have specific data validation that is tough to test using the generated code, you can push in the breaking method. You can add your individual specific tests to the Java source of he integration test. And you also get an entity manager.

    However, the problem might be the DataOnDemand class. There are a feet methods in that ITD that you can push in, ones that generate fake data.

    Above all, Spring Roo is a Spring platform. So anything you can do in Spring you can do there. Hence 9.4.2 shows how to create a Java test class and write one yourself.


    • #3
      Okay, I didn't know if I had to make use of some Roo high chaparal magic :-)

      So, I'll do like I did with my old standard Dao and use the @Autowired annotation like you suggested.

      Thanks for the kind comment.


      • #4
        I'm not sure I'm supposed to inject the repository with the @Autowired annotation.

        This gives an error at compile time with Maven saying there is a conflict of member variables between the one in the test class and the one in the test aspect class.

        In the AddressIntegrationTest_Roo_IntegrationTest class there is:

        AddressRepository AddressIntegrationTest.addressRepository;
        And in the AddressIntegrationTest class there is:

        AddressRepository addressRepository;
        And the compile does not like it.


        • #5
          I was discussing how to build your own integration test. If you are trying to use an existing repository integration test ( with @RooIntegrationTest) then the ITD already injects it. That is if you created automated repositories for your entities with the repository creation command.

          You can add your own methods to the Roo integration tests. Just add them to the Java class. In that one, the ITD makes all test methods transactional anyway.


          • #6
            One more thing. If you created Roo services for your entities and Roo repositories, then Roo will test at the service level. The ITD should have a reference to the service but not the repo at that point.


            • #7
              Hi Ken,

              Thanks for the sharing ! Indeed I had removed the @Autowired annotation and the member variable for the repository from the test class and the conflict disappeared.

              Only, now I'm fighting with a memory issue as my schema seems to have too many tables for my Maven build.

              But that's another thread...
              Last edited by stephaneeybert; Oct 8th, 2012, 03:56 PM.