Brian,
we seem to have different views on the semantics of the word bug or
enhancement :-) To me a bug is when an expected behaviour is not
verified. What you're trying to do is legitimate but was never
considered before as a scenario. It turns out that (most likely) we
need to overcome the implicit assumption of the uniqueness of the
parameter names. But we should not focus on the semantics, rather on
getting the expected behaviour implemented and verified.
The delimiters are already stored in the ParameterControls so we can
easily pass it into the ExamplesTable (via the method
getRowsAsParameters()).
I've tried applying your patch to ExamplesTable but it does not seem to
have made much difference (fails still, albeit for different reasons).
So, please feel free to create a new issue for this and let's work
together on reproducing the desired behaviour in parametrised_table.story.
Let's touch base on IM when you can.
Cheers
On 28/02/2012 13:51, Brian Repko wrote:
Trimming this email down - I've patched ExamplesTable at
https://github.com/brianrepko/jbehave-core/commit/364c27fd7c59a60933c2f7c1245d59a58f22d901
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" <mauro.tal...@aquilonia.org
<mailto:mauro.tal...@aquilonia.org>>
To: dev@jbehave.codehaus.org <mailto: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
