Skip to Main Content
Forums

SQL Developer

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.

Best Practices for working with SQL Developer Unit Test module

PyrocksNov 27 2014

Hi,

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.

Thanks.

Comments

santiago_nc

I don't fix this yet.

santiago_nc

Any help?

Hi,

Why not use MDS? Why you've to re-create the VO just for changing it's UI hints and properties?

Check out this sample : http://andrejusb.blogspot.in/2014/04/mds-seeded-customization-approach-with.html

-Arun

santiago_nc

Hi,

I have to recreate the VO at runtime since I could change the query, add different LOV to an attribute at runtime, etc Really, the ViewObject created by jDveloper is a template which I could change at runtime with meta-data saved in DataBase.

Each application is a TaskFlow pageFragment based which is rendered as a Region. Then, It could show same application in two regions, showing different ViewObject Instances at runtime.

1 - 4
Locked Post
New comments cannot be posted to this locked post.

Post Details

Locked on Dec 25 2014
Added on Nov 27 2014
#sql-developer
0 comments
509 views