[Rspec-devel] BDD Question - wheres the BDD help forums?

First Name Last Name kognition at gmail.com
Fri Jul 14 06:54:55 EDT 2006

Hi Chris,

I think the problem I have is that the spec. I have created isnt clear.  In
the View, all it does is pick up a button event, and then raise that Action
event.  The Presenter is the object that listens for that business event and
then maps it to the model by asking to create an account.  The view does
nothing other than render and raise events from the UI.

In my problem the question I am facing is, do I get the presenter to invoke
on the model, then, take the new account from the model and pass it up to
the view (this would be Presenter First).  Or, do I allow the presenter to
call onto the model, and have the view listen to events on the model as
well.  When the model raises the OnCreatedNewAccount event, the view picks
this up and renders it - because it specifically subscribed to that model
event for a reason.  However, I never actually test the view with this
approach.  To test the true view, I need to drag over the actual C#
WinForms/UserControl for testing, testing that it actually sets its Account
when the model raises an event.  I can do this, and have done this, rather
than mocking view which would mena I dont actually test the view.  I did
some benchmarks today, and a simple fixture of 5 tests using the latest
NUnit takes half a second longer when calling onto the UserControl view.
When view is stubbed, the tests run at 0.51 secs, without stubbing they run
at 0.98 consistently.  Theres only 5 tests so this is a doubling in the time
it takes to run the tests, and is an alarm bell to me to consider Presenter
First just for the testing forces it works with.



On 7/14/06, Chris Anderson <jchris at mfdz.com> wrote:
> Hi all,
> Just a little chime in here:
> It seems like explicitly raising the new account created event from
> the view, has a little bit too much of the internals of the view being
> messed with in your test. If there is a way to provoke the view to
> raise that event based on the input it usually recieves in normal
> operation, that would seem more like a spec to me. Of course, you may
> not want to couple your view to tightly to your client parameters, but
> at some point in your testing you'll want to ensure that your
> application responds to client input as it should.
> Your view seems smarter than the one's I'm familiar with (I'm a Rails
> guy) but maybe that is the Presenter pattern. To me, the details of
> translating a client request into a new account (the parameter
> mapping) should happen in the application code, not the view.
> But, again, I am naive about your context, and there are certainly
> things that weigh in favor of the simplicity of your specification.
> Do any of you on the list have opinions about whether the
> request-response cycle should happen in the setup or the specify
> block?
> --
> Chris Anderson
> http://jchris.mfdz.com/
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060714/d3d1a7fc/attachment.html 

More information about the Rspec-devel mailing list