Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Slim support #31

Open
5 tasks
benilovj opened this issue Mar 6, 2013 · 17 comments
Open
5 tasks

Slim support #31

benilovj opened this issue Mar 6, 2013 · 17 comments

Comments

@benilovj
Copy link
Member

benilovj commented Mar 6, 2013

The background

Currently, as the name would suggest, DbFit only supports the Fit test system for FitNesse. This feature is about adding Slim test system (note that we don't want to drop Fit support any time soon).

The main complexity of this feature will come from having to untangle the Fit-specific table and data type parsing from the test-framework part of the DbFit core.

Another current unknown is how DbFit's flow mode will translate to Slim; flow mode makes sure that the test automatically executes in a transaction, so that the user doesn't have to worry about it.

Definition of Done

This is a substancial piece of work to do cleanly, involving the following:

  • an initial spike to figure out how flow mode will work in Slim
  • defining a DbFit-equivalent syntax in Slim. This is analysis work which involves:
    • learning what's possible within Slim
    • identifying the least-noisy syntax to achieve the same thing as in DbFit)
  • separating the database and Fit-specific logic in classes within the core component (currently, there's quite tight coupling in a few places) - this is Java refactoring work.
  • implementing the Slim fixtures
  • porting the acceptance tests to Slim

This feature will involve touching most of the core of DbFit. I would like to use this opportunity to pay back a lot of tech debt, specifically:

  • introduce better separation of the following concerns (ie distinct, separate classes and packages):
    • the table parsing
    • test framework code
    • database access parts of dbfit should all be distinct)
  • introduce unit tests

The proposed technical approach

I would like to apply an acceptance-test-driven approach:

  1. pick a existing DbFit acceptance test from the Derby test suite (Derby because it's the only test suite that's in pure java, making it suitable to run outside of the VM).
  2. define the equivalent Slim FitNesse page
  3. stub out enough of the Slim fixtures for the test to fail (as opposed to raising exceptions)
  4. refactor the existing Fit-based code to allow clean integration with the Slim fixtures
  5. wire up the Slim fixtures until the test passes
  6. repeat steps 1-5 with the next Derby test, etc
@tombeuckelaere
Copy link

Is there any progress concerning this matter?
We are also very interested in DBFit working with slim.
Combining Xebium (slim) with DbFit would be a runner up for our project.

@benilovj
Copy link
Member Author

hi @tombeuckelaere, we've recently done some groundwork to make the port to slim easier, but to be honest, I think it's still a long way away - it's a very large task (because DbFit is very intertwined with Fit) and pretty thankless to boot (lots of edge cases that aren't covered by tests at the moment, because the current implementation isn't really unit-testable).

@MMatten
Copy link
Contributor

MMatten commented Nov 30, 2015

Some interesting development from the FitNesse community that could be a useful resource at some point: -

https://groups.yahoo.com/neo/groups/fitnesse/conversations/messages/21422
https://github.com/six42/jdbcslim

@thomas-romuald
Copy link

Hi, our team just have the same issue.
Is there any progress to use DbFit on an existing Fitnesse test module based on Slim ?

@niamhkelly
Copy link

@benilovj Can you let me know if there is any progress with using Dbfit with Slim? I notice the six42 project has jdbcslim available (https://github.com/six42/jdbcslim/blob/master/FitNesseRoot/PlugIns/JdbcSlim/Installation/content.txt) - i need to know is this my best option? Also i need to run it with the latest fitnesse jar. My team currently have a full suite of tests running on slim server - i have dbfit running standalone using oracle-dbfit but once i integrate, i can't find a way to run the fit server seamlessly.

@benilovj
Copy link
Member Author

@niamhkelly @thomas-romuald I'm not involved with the DbFit project anymore. @javornikolov or @MMatten any comments from you guys?

@niamhkelly
Copy link

@benilovj thanks for your reply. I contacted six42 and he replied saying his jdbcslim should solve the problem. The syntax is not identical to dbfit so i need to adjust my existing dbfit tests. It will work with the latest fitnesse.jar

@MMatten
Copy link
Contributor

MMatten commented Mar 22, 2017

@niamhkelly @thomas-romuald We have still not made much progress towards a SLIM based implementation, mainly because of lack of available time over the last year.

We have recently been working on a new (Fit based) release though and we will probably complete this in the next few weeks. This will be compatible with the latest FitNesse version so you could at least have your SLIM and DbFit tests running under the same FitNesse server.

I've not used JdbcSlim myself so I can't really comment on whether this is a better option for you, at least in the short term (until we have a SLIM based DbFit available). From a very quick glance it appears to be fairly comprehensive in terms of features.

Do you need to tightly integrate your existing SLIM (non database) tests with SLIM based database tests, or simply to be able to host your SLIM tests and DbFit tests on the same FitNesse server/host?

When we've completed the next release we could/should consider turning DbFit towards SLIM. @javornikolov any thoughts?

@niamhkelly
Copy link

@MMatten Thanks for your reply. Great to hear more work is planned.
We need to host our Slim suites and Dbfit suite on the same fitnesse server.

We have a common setup at the top level where all global variables setup, in addition a common fixture required for loading zookeeper properties so our suites can be run in multiple environments. With this common setup, dbfit needs to run on the same server. I couldn't find a way to start the fit tests first, then slim within the one setup

@MMatten
Copy link
Contributor

MMatten commented Mar 22, 2017

@niamhkelly You can't mix SLIM and Fit (such as DbFit) tests on the same test page. But you should be able to have a single suite with mixed SLIM and Fit test pages as long as the test system is defined appropriately (e.g. in each test page, or in a sub-suite).

There's a similar discussion here: http://fitnesse.996250.n3.nabble.com/Suite-with-both-FIT-and-SLIM-td7909.html

@niamhkelly
Copy link

@MMatten
I don't have a mix on the same page. I have a database subsuite where i declare the fit server in it's own setup: !define TEST_RUNNER {fit.FitServer}.
Then for the slim suites, i have defined the Slim server for it's own setup: !define TEST_SYSTEM {slim}.
But i found once the Suite began executing the same fitnesse server stayed running throughout

@niamhkelly
Copy link

@MMatten One other issue i found - after experimenting with connection strings for an oracle database, i needed to specify the username and password in the connection string. When the suite is run the connection string is shown with username and password in the fitnesse results. Is there a way of hiding the string as its a security concern?
Example:
!|Connect|jdbc:oracle:thin:${DB_USERNAME}/${DB_PASSWORD}@(DESCRIPTION =(SDU = 32768)(enable = broken)(LOAD_BALANCE = yes)(ADDRESS = (PROTOCOL = TCP)(HOST = ${SERVER})(PORT = ${PORT}))(CONNECT_DATA =(SERVICE_NAME = ${SNAME})))|

@MMatten
Copy link
Contributor

MMatten commented Mar 22, 2017

Is there a way of hiding the string as its a security concern?

You can use the |Connect Using File| method to prevent these details from being displayed in the FitNesse UI and also to abstract the connection details to make the tests more portable between environments.

@MMatten
Copy link
Contributor

MMatten commented Mar 22, 2017

I've created a basic test of a single suite with two test pages.

One page includes !define TEST_SYSTEM {fit} and the other !define TEST_SYSTEM {slim}.

I can run both tests successfully by running the suite as a whole. Is this the same kind of thing as you're doing?

@niamhkelly
Copy link

@MMatten thanks for your help and testing this
Yes that's how i have my suites setup - subsuites for each server type and associated tests, where the server is defined in each Setup.
I'm using !define TEST_RUNNER {fit.FitServer} for dbfit. Also our main fitnesse jar is the latest jar used by our slim suite.
I'll experiment more

@javornikolov
Copy link
Contributor

Yes, after the upcoming DbFit release I believe we can look into researching Slim and what would might be done to integrate DbFit with it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants