0 Replies Latest reply on Nov 27, 2014 7:36 AM by Pyrocks

    Best Practices for working with SQL Developer Unit Test module





      My company wants to start using SQL Developer as our DB Unit Testing tool.

      However, we are not quite sure how to maintain it in our source control, and how to use the files once they are there.


      I'll explain:

      1. Granularity of items kept in Source Control:
        When Exporting a Suite - the generated XML file contains the Suite definition but also the definitions all of it's linked Suites, Tests, Libraries etc.
        We thought about Using a root Suite to run all the other Suites and Tests in one go and keep that in in our source control- but this is problematic since each developer would be locking the entire UT tree for his/her modifications - No working in parallel (SQL Developer doesn't provide means for merging or comparing exported UT XMLs or UT repositories).
        So now we are thinking about saving all of the pieces separately - Tests and Library definitions, and not working with Suites at all. This would allow developers to check in just what they are working on and not interfere other developers.
        The problem with this approach is that it would more troublesome to import all of the separate files, let alone having to run multiple (can get to hundreds of) tests instead  of a single Suite (I also assume running would take more time).
        It would have been best if there was an option to export Suites with just the references to the used items but without their actual definition, or alternatively, some way to automatically generate Suites for imported tests according to some rules.
      2. Repositories:
        Is it better to have a single master UT repository for all developers to use for their testing - or each developer working on his own repository (importing from the master) to not interfere/override someone else's work?
        Since Repository creation can't be done through CLI (command line interface)- I assume duplicating the UT Repository schema would work.
      3. CLI
        There are a bunch of things doable from the GUI, but aren't doable through CLI.
        This puts sticks in the wheels of trying to automate the unit testing process - which leads us to sometime reverse engineer what the GUI does and implement it on our own using packages on the UT repository (in example - purging the repository or the results).


      Any guidance would be appreciated.