Skip to content

Project set up and package options

Jump to bottom
Richard Tomlinson edited this page Jul 7, 2016 · 6 revisions

A set of JBehave unit tests consist of:

  • The test stories in '.story' files
  • Test data used by the mocks and when invoking services
  • A Java class file which the JUnit running within Eclipse identifies as a test and that then executes the stories
  • Dependencies on the wm-jbehave and JUnit jar files for the test running

There are a number of ways which these artefacts can be applied so that they are runnable within Designer.

Options for structuring tests within a project

The tests can live in one of three places:

1. Within their own Java project, independent of any IS package.

  • Pros
    • Leaves the IS package which they are testing untouched
    • No mixing of tests with services
  • Cons
    • If you are wanting to run the tests for every check-in, such as executing with Jenkins/Bamboo/etc then this separation is complicated to configure
    • Nowhere to put additional test related services other than actual IS package which may be undesired to mix 'production' and test code
    • Developers have to check-out the IS package and the test package which can lead to reluctance and avoidance in writing tests

2. Create a separate IS test package (E.g named as the package under test appended with 'Test') and embed within

  • Pros
    • Can add additional test services
  • Cons
    • Not gaining much over having separate Java project

3. Add tests to IS Package under test

  • Pros
    • Can trigger Continuous Integration testing easily when check-ins occur on the package
    • Keeps all in one place - Same approach if developing Java solutions
    • IS Package can be imported into Designer as separate project and likely already have a mount point if remote server
  • Cons
    • If wanting a 'pure' IS package for deployment, need to remove the test directories before zipping, etc into a deployable artefact - Simple process if using Jenkins, etc

Based on experience of trying the methods, the recommended approach is to use the third option of adding in to the IS package then at build time removing test content before creating an artefact (Ie a zip/jar which is used as the basis for the deployment process). Its been shown to make it easier for the developer, uncomplicated when involving a continuous integration process and the automated test sanitisation of the package is a simple step to implement.

Clone this wiki locally