3

If I have a test that requires X widgets as a precondition, I'd like to avoid the tedious process of making X widgets in the test through the front-end. The main alternatives appear to be either having a stated DB dump that is loaded for each test run, guaranteeing a pre-determined state (the dump file is generated by doing the preconditions manually and then dumping the resulting schema), or by using an ORM.

Given that all of our business logic sits at the application layer, replicating it with an ORM (Hibernate) has proven to be unwieldy. My Selenium framework is in Java, the app is in PHP using symfony.

What are the options? Have really long tests, somehow call symfony/PHP commands from Java, or have a difficult to maintain dump file in the repo? Should I be using transactions instead on a preset DB? It is key to optimize the trade off of test run-time and writing/maintenance simplicity. I've been looking at tools like DbUnit to perhaps help.

dhackner
  • 2,942
  • 2
  • 20
  • 23
  • Your priority should probably be to refactor the business logic out of the application layer. Among other things, it will be much easier to unit test the business logic without having to deal with UI automation tools. Once you have a proper business layer, generating valid test data in a maintainable, clear way is pretty straight-forward. – Michael Maddox Sep 13 '10 at 10:51
  • I think that my terminology was incorrect. I meant to say that our business logic is split between PHP and symfony calls, so just calling symfony from Java wouldn't be sufficient, I'd need to access PHP functions. If the logic is correctly layered, what is the ideal method? Using a master DB, or calling business logic? – dhackner Sep 13 '10 at 20:27
  • Calling business logic is more ideal in my experience, although you can make either work. – Michael Maddox Sep 14 '10 at 09:52
  • Michael Maddox: if you would like to provide some examples and elaborate a bit, I will accept your answer. – dhackner Sep 16 '10 at 17:03

0 Answers0