Mauro Talevi commented on Story JBEHAVE-785

Finding a balance on how to represent data effectively is a tricky thing.

In a BDD approach, where communication is key, is it recommendable to keep them in the story file and not separate them, as it is more readable and shareable. Otherwise, having multiple table files is an option, but not recommendable in the end.

The examples tables have at the moment a simple but non-extensible processing interpretation. To have an extensible entry point may be possible, but we need to look into it and weight the pros and cons. Your proposal would mean having to parse the table file and exact the tables, which leads to yet another layer of grammar, which may not be intuitive.

I would perhaps see more practical to introduce some mechanism to filter out by meta tags the rows you are interested in from a single table.

Scenario: +Login2: User Logs into the Application with incorrect password+

Meta: @env UAT 

Given I log into Application as valid user <username> with invalid password <password>

Examples:
../Login1.table

Login1.table
------------
|env|username|password|
|UAT|ABC|invalidpassword|
|SIT|XYZ|anotherpassword|

More in general, JBehave is designed to be customisable but to a limit. There are some features whose logic is hard-coded.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email

Reply via email to