issues / disadvantages of the unit testing framework
687216Aug 4 2010 — edited Aug 20 2010Hi everyone,
we've decided to try the unit testing framework integrated into SQL Developer no a new project (we've been using utplsql in the past). Generally it works but we have found some issues / disadvantages compared to utplsql:
1) The unit tests are linked directly to the functions / procedures, including schema, which means you can't have multiple schemas (each with different sets of testing data for example) and functions/procedures using definer rights. And you can't move (export/import) the tests to a different database unless the schema names etc. match perfectly (which is often the case during development). The only workaround we've found is editing the XML file, which is something I really don't like as it iterferes with the version control system we use (the file is considered 'modified' although).
2) It's not possible to debug the unit tests (e.g. to place a breakpoint and use the usual debugging options). The only thing I've found is a 'debug' button that prints an unusable details about the execution. Moreover the text area used to enter the PL/SQL code is just a plain textbox, with no code insight (so we're developing the tests in a plain SQL worksheet), and then copying the code into the unit test.
3) There is no place intended for description of the unit test (a header, what is it testing etc.). You can't actually use any of the editable areas (tearup, teardown, validation) as these may be referencing a library items, i.e. shared among multiple tests.
4) It's designed to test individual procedures / functions, so if you want to test a whole process (calling multiple procedures) you need to wrap that into a completely new procedure. You can't create a unit test not linked to an existing function/procedure.
5) Renaming a tested function / procedure makes the test invalid, and there's no way to make it work except for editing the XML (again).
I could probably name a few more but these four are the most annoying ones - especially the second one (no debugging), which makes fixing the tests much slower. Have you solved any of the issues or have you found another (better) workarounds?
I understand this is a quite fresh feature, and I hope some of the issues will be addressed in the next versions, but for now I'm thinking about switching back to utplsql.