Including one concordion html file into another

[shafali kataria]

Anybody aware about how to include one specification file into another

Like i have 4 steps in each test i.e. Login , fill data , perform db validations and then log out

I dont want to duplicate code into each test and want to have login logout file in each test case.

Any examples will help.

Thanks in advance

[Troy Best]

The run command lets you run another specification from within a specification. I am new to Concordion and have not used this approach yet so I do not know if there are any caveats or side effects. 

[Tim Wright]

Hey,

Another option is to move your shared fixture code into either a base class or a utils class and use it from there. Note that if you use the "@Before" annotation or mark an example as "before" then that code will run before each example in the fixture - which might be useful if you have common setup code that has to run before each test.

See http://concordion.org/instrumenting/java/markdown/#example-command for some more information about using examples in concordion. It's a new concordion feature that runs each example in a fixture as a seperate junit test.

Tim

--

Tim

021 251 5593

http://www.linkedin.com/in/drtimwright 

--
You received this message because you are subscribed to the Google Groups "concordion-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to concordion-dev+unsubscribe@googlegroups.com.
To post to this group, send email to concordion-dev@googlegroups.com.
Visit this group at https://groups.google.com/group/concordion-dev.
To view this discussion on the web, visit https://groups.google.com/d/msgid/concordion-dev/a8e27db8-661b-4531-8f8a-cf0b6c3038a4%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Nigel Charman]

Rather than writing this as a test script that lists all the steps, the specification should focus on the business need at a higher level of abstraction. It shouldn't need to mention login, logout and possibly not even that a database is being used. The specification should be in plain language that everyone can understand and contain the minimum amount of detail to understand each example.

For example, your example might read "When a product code of 12345 is entered with a discount of 40%, it is ruled as invalid" (I have no idea what business domain you are working in).

The details around logging in and out should be handled by the fixture, using one of the method hooks such as @BeforeExample and @AfterExample, or the "before" example as suggested by Tim.

If the data is complex, you should specify just the attributes of the data that are important for this example, and hide the other attributes in the fixture (for example using the Test Data Builder pattern).

If you need to reveal the actual data that is being used, you should use one of the Concordion extensions, such as Logging Tooltip or Logback to make the details available to anyone interested in how the spec has been implemented.

For more description about these approaches, see the Hints and Tips.

Please reach out if you have questions about this.