Hi Ken, BDD can be used to verify any system’s behaviour that can be automated.
The tricky bit is to describe the behaviour in a way that is intelligible from a business point of view (big files aren’t as you’ve noted). You may try to autogenerate the input files based on templates with the relevant scenario values being exposes in steps or tables. As for batch-oriented systems, BDD can surely be of help but you need to design the scenarios to ensure the execution of the required transactions. If you use multi-threading you need to make sure that all the threads are complete before the results are verified. Typically this can be realised easily with a single step, e.g. When all transactions are completed Please note that each scenario is meant as a self-contained use-case so you should not have one scenario rely on the the results obtained from other scenarios. You can use GivenStories or other Before steps to ensure the state of the system before a scenario or story. Cheers > On 17 Aug 2017, at 03:41, Ken Van Camp <[email protected]> wrote: > > I am new to JBehave, but very familiar with BDD concepts and would like to > try to follow them on a new batch-oriented system we are starting development > on. I'm on the development side, but our "QA team" is responsible for all > automated testing (yeah I know right away that's a contradiction wrt BDD). > They are experienced in JBehave but they are really only trying to use it as > an automated testing tool, and I'm trying to convince them that the natural > language features allow for much more. (Since we are developing a > batch-oriented system, with files as input and files as output, they want to > write one JBehave scenario which takes their big input file, processes it, > then compares the output files against expectations. But the scenarios are > therefore not human-readable, so it seems we are getting very little benefit > from using JBehave.) > > Does anyone have experience in testing batch-oriented systems in JBehave? It > seems like tests normally execute sequentially, but this poses a problem for > a batch system that is not designed for good performance in processing a > single transaction. Therefore, I think we should be building up a "batch" of > small tests in which each scenario generates a transaction then all the > transactions are pulled together into a single input file. The input file is > processed, then the results are gathered. We have a single unique key on each > transaction so it is easy to match up results to inputs, and compare expected > vs. actual values. So now we have to go back to our original scenarios to > compare the "THEN" clauses on each one and report results. > > Can it work in JBehave? Or is there a better way to do this? Thanks. > Ken > > -- > You received this message because you are subscribed to the Google Groups > "JBehave User" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > To view this discussion on the web, visit > https://groups.google.com/d/msgid/jbehave-user/45765ed9-fab0-4440-890a-1a38bf73fb7f%40googlegroups.com > > <https://groups.google.com/d/msgid/jbehave-user/45765ed9-fab0-4440-890a-1a38bf73fb7f%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "JBehave User" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send an email to [email protected]. To view this discussion on the web, visit https://groups.google.com/d/msgid/jbehave-user/93865232-A353-40F7-87AA-26CC6109C5A5%40aquilonia.org. For more options, visit https://groups.google.com/d/optout.
