GWT delegate names
powerdude
I've been playing around and really enjoying the code. Since i'm
using delegates, it's been a bit challenging to get the methods to
group or be discoverable. Would it be possible, when outputting the
step name, to strip Given, When, and Then from the beginning of the
method names?
cliff
cliff vaughn
public void AddTwoNumbers()
{
Add(GivenANewCalculator);
Add(WhenAdding,1,2);
Add(ThenResultIs,2);
}
and have it create the scenario based on the names.
cliff
thanks
cliff
Jason Diamond
I see what you mean now.
By "discoverable", you want to use IntelliSense to find the methods
that are used for Givens separate from the ones that are used for
Whens, right?
I definitely see that as being useful.
Are you suggesting that we add "Add" methods in addition to the
existing Given, When, Then, and And methods or just replace them?
I don't want to overwhelm new users with too many options. So far,
you're the first person using the delegate syntax (you're really the
first person using BehaveN outside my team at my day job period) so I
might defer to your opinion on what you think the best approach would
be.
By the way, why do you prefer the delegate syntax over the plain text syntax?
--
Jason
cliff vaughn
Hi Cliff,
I see what you mean now.
By "discoverable", you want to use IntelliSense to find the methods
that are used for Givens separate from the ones that are used for
Whens, right?
Yes!!
I definitely see that as being useful.
Are you suggesting that we add "Add" methods in addition to the
existing Given, When, Then, and And methods or just replace them?
Well, there currently is an AddStep, and i considered using it, but i'd have to provide too many parameters, and to me, the name is too long. The parameters will tell me what i'm adding.
based on how i'm using it, i'd never use the Given, When, Then, & And methods if Add were there. There might be a use case to use them if a user didn't want to prefix their methods with GWT, or if they followed the technique you had on the site about grouping the delegates in a classes.
I don't want to overwhelm new users with too many options. So far,
you're the first person using the delegate syntax (you're really the
first person using BehaveN outside my team at my day job period) so I
might defer to your opinion on what you think the best approach would
be.
I don't think you should be worried about overwhelming the user. You've got a pretty simple API currently, even if there are a bunch of overloads. It's not that different from NUnit and the original "Assert." API.
By the way, why do you prefer the delegate syntax over the plain text syntax?
I prefer it because i'm not too keen on managing a text file somewhere. I'm constantly refactoring, thanks to Resharper, and using the text file would kill the velocity i have when coding. Besides, i get compile time errors versus run-time errors and can fix things that much sooner rather than worry about regex or other fat-finger mistakes.
cliff
--
Jason
On Sat, Aug 15, 2009 at 1:38 PM, cliff vaughn<clifton...@gmail.com> wrote:
> after some more playing, what i'd really want to do is
>
> public void AddTwoNumbers()
> {
> Add(GivenANewCalculator);
> Add(WhenAdding,1,2);
> Add(ThenResultIs,2);
> }
>
> and have it create the scenario based on the names.
>
> cliff
>
> On Sat, Aug 15, 2009 at 4:22 PM, powerdude <clifton...@gmail.com> wrote:
>>
>> Jason,
>>
>> I've been playing around and really enjoying the code. Since i'm
>> using delegates, it's been a bit challenging to get the methods to
>> group or be discoverable. Would it be possible, when outputting the
>> step name, to strip Given, When, and Then from the beginning of the
>> method names?
>>
>> cliff
>
>
> --
> thanks
>
> cliff
>
--
thanks
cliff
Jason Diamond
On Sat, Aug 15, 2009 at 2:57 PM, cliff vaughn<clifton...@gmail.com> wrote:
> Well, there currently is an AddStep, and i considered using it, but i'd have
> to provide too many parameters, and to me, the name is too long. The
> parameters will tell me what i'm adding.
Hmm, I didn't realize AddStep was visible. It was only meant for
internal use, but I had to mark it protected so that the subclasses
(Scenario and ContextSpecification) could access it. I'll see if I can
"hide" that somehow.
>> By the way, why do you prefer the delegate syntax over the plain text
>> syntax?
>
> I prefer it because i'm not too keen on managing a text file somewhere. I'm
> constantly refactoring, thanks to Resharper, and using the text file would
> kill the velocity i have when coding. Besides, i get compile time errors
> versus run-time errors and can fix things that much sooner rather than worry
> about regex or other fat-finger mistakes.
That makes sense. I have it listed on the PlainText page on the wiki
as an advantage of using code instead of plain text files.
We use a lot of grids in our tests and that's where the plain text
syntax shines. I'd like to think of a way to get the delegate syntax
to be as convenient for specifying that kind of data.
Our main reason for using plain text is so that our product owner (we
do Scrum) could write them up himself. He doesn't yet, but I'm hoping
he will at some point. In the meantime, we can show him the plain text
and he can read it.
If I could get the delegate syntax to output plain text syntax, we
could just copy/paste the output and show him that.
--
Jason
cliff vaughn
Hmm, I didn't realize AddStep was visible. It was only meant for
internal use, but I had to mark it protected so that the subclasses
(Scenario and ContextSpecification) could access it. I'll see if I can
"hide" that somehow.
mark it protected internal.
That makes sense. I have it listed on the PlainText page on the wiki
>> By the way, why do you prefer the delegate syntax over the plain text
>> syntax?
>
> I prefer it because i'm not too keen on managing a text file somewhere. I'm
> constantly refactoring, thanks to Resharper, and using the text file would
> kill the velocity i have when coding. Besides, i get compile time errors
> versus run-time errors and can fix things that much sooner rather than worry
> about regex or other fat-finger mistakes.
as an advantage of using code instead of plain text files.
We use a lot of grids in our tests and that's where the plain text
syntax shines. I'd like to think of a way to get the delegate syntax
to be as convenient for specifying that kind of data.
I'm thinking about looking at the grid/form stuff, so maybe i'll be able to provide some assistance/recommendations with that.
--
thanks
cliff
Jason Diamond
On Sat, Aug 15, 2009 at 4:43 PM, cliff vaughn<clifton...@gmail.com> wrote:
> mark it protected internal.
That means protected OR internal.
http://haacked.com/archive/2007/10/29/what-does-protected-internal-mean.aspx
I just checked in some changes to make AddStep more difficult to find.
I added your suggestions about the Add method and not repeating the
step type to my TODO.txt file. I have to get going now (had to spend
most of today doing real work), but maybe tomorrow I can implement it.
> I'm thinking about looking at the grid/form stuff, so maybe i'll be able to
> provide some assistance/recommendations with that.
My current thinking is that you would construct your normal objects
and pass them in as arguments. When outputting a description, BehaveN
would try to guess at which argument was the form or grid. If it's a
"simple" type (string, int, decimal, DateTime, etc), it can't be
either. If it's a IEnumerable<T> of some non-simple type, it must be a
grid. Otherwise, it's a form.
You can only have one of these per step in the plain text syntax. I
suspect we'd want to keep that restriction for the delegate syntax,
too, otherwise the report would look weird. Where does one form begin
and the other end?
--
Jason
cliff vaughn
thanks
cliff