fitnessedbfit

How can I manage different DBMS in DBFit?


sorry for my English, I speak Spanish.

I have a test suite for Oracle, and now I need to maintain the same suite but for SQLServer as well.

Queries are the same, but have slight differences (date functions, etc).

What is the best way to manage a suite that needs to be multi-dbms?

Thanks


Solution

  • I don't have any experiences using DbFit, so my answer is generic. Hopefully you can use it as a basis for your exact problem.

    To me managing slightly different test suites brings to mind one of the approaches below:

    1. Using Symbolic Links to maintain a single set of pages to create a suite (sub-wiki) per environment. The pages define the test cases and per environment there is a root page that defines symbols ('wiki variables') and a link to the set of pages.
    2. (When using Slim) use different scenarios per environment/database system. You could either include different pages defining the scenarios (each defining scenarios with the same name, but with different definitions) based on what should be currently tested. Or use symbols in your scenario calls to call different scenarios based on the current environment. In both cases you could, of course, have shared scenarios applicable in all cases.
    3. Use different fixtures for each environment, allowing different implementation of the same methods.

    I believe your usage of DbFit excludes options 2 and 3, so option 1 seems the one to go for. Specifically I believe that will mean defining symbols (e.g. !define QUERY_1 {...}) for the query-parts) and connection strings that need to vary per DBMS. In the test cases you do not hard-code these, but include references to the symbols (e.g. ${QUERY_1}) instead. (See also my answer to Can FitNesse page tags be used in page?)

    But of course all this depends on what your testing needs are exactly. I tend to use FitNesse to do acceptance testing on applications. So I would tests application end-user or service/API functionality and not database queries. In such a case I will not run all tests against all DBMSs to be tested (I would expect the database layer component tests to test all queries against all databases). I would run the majority of the acceptance suite against one DBMS and a very limited set against the others.