Trimming this email down - I've patched ExamplesTable at https://github.com/brianrepko/jbehave-core/commit/364c27fd7c59a60 933c2f7c1245d59a58f22d901
The edits to the story were to make the user names unique between the two scenarios - that was causing a problem that was hidden before. So here may be the crux of the disconnect - I use tables as ways to combine multiple steps. So instead of "And the username is <username>", "And the password is <password>" ...I use a 2 row table to represent name/value pairs. This is very useful for setting particular fields of a domain object or working with multiple but not all fields of a dialog. So what you see as 2 tables is not really - the scenario is parameterized but the Given step takes a table parameter. This is no different than the scenario on the website - http://jbehave.org/reference/stable/tabular-parameters.html - in the Parameterised Tables section (which wouldn't work by the way unless you code for the "<" and ">"). So, yes, I was able to get it to work by duplicating the data and giving it a different name - that is a hack around a bug. That does not make it an enhancement. And that still doesn't fix the problem of name collision that was in the original email and is clear from the code that I changed. I understand your suggestion - the deal with that is that I stil have to pass in the values!? And that I'm using a Builder pattern so that I only need to use the properties that I'm changing. Much more reusable steps code. Please look at the fix to ExampleTable - I think you'll see what the problem is. You may have to go back to an earlier email for the full series of fail. I think gettting the example on the website into the actual examples would be ideal since the spring-security example is not part of the regression suite. The design issue is where to store and override the delimiters used for parameters in ExampleTable objects. I prefer the Keywords with overrides at the table level (prefix / suffix). But I thought I'd leave that up to discussion. And to me this is a bug - after reading this, if you agree, just create the bug. If you don't you can IM me or email me. No worries Ta, Brian ----- Original message ----- From: "Mauro Talevi" <[1]mauro.tal...@aquilonia.org> To: [2]dev@jbehave.codehaus.org Date: Tue, 28 Feb 2012 11:35:56 +0100 Subject: Re: [jbehave-dev] potential bug? Hi Brian, I'm now able to reproduce behaviour - I think I was misled by the noise of debug :-) I've pushed a change by which the non-working scenario is skipped until we get it working. The problem with it is that you want to reuse the same parameter names in the two tables. To me it's all a bit confusing. While it may be a legitimate request, I wouldn't consider it a bug, rather an enhancement or a new usecase. In fact, you can get it to work by using unique names. Can we please try to reproduce the desired behaviour in the parametrised_table.story? The bare-bone essential feature only. For the time being, I would suggest you could change the language to something along the lines of : Given the users for Microsoft with properties: username, passwordCleartext, enabled, expired, forcePasswordChange Thus avoiding the double table - which feels a bit redundant here in any case. Cheers References 1. mailto:mauro.tal...@aquilonia.org 2. mailto:dev@jbehave.codehaus.org
