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

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


Another question I have is is related to your last point Chris.  When the
View raises the OnCreateNewAccount event two things need to happen within
the presenter:

1. The presenter calls onto the model and the model creates new account
2. The presenter sets the new account onto the view

My "context" is "A newly created Presenter", and I am specifiying what
happens when the OnCreateNewAccount event is raised in this context.  I have
two specs now with duplication:

public void ShouldAllowNewAccountToBeCreated() {
    int numberOfAccounts = myAccountsModel.Accounts;


    Assert.AreEqual(numberOfAccounts + 1, myAccountsModel.Accounts);

public void ShouldAssignNewAccountOntoTheView() {


Here the myView... line is duplicated in both specs.  Is this ok, or should
I be thinking about pulling this out some how? My other thought is that this
approach of raising the View event, which is taken from Martin Fowlers MVP
discussion, doesnt actually make anything clear.  It feels better to be more
explicit in the spec:

public void ShouldAllowNewAccountToBeCreated() {
    int numberOfAccounts = myAccountsModel.Accounts;

    /*** Change the View invoke to Presenter ***/

    Assert.AreEqual(numberOfAccounts + 1, myAccountsModel.Accounts);
Any thoughts?


On 7/14/06, First Name Last Name <kognition at gmail.com> wrote:
>  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.
> Thanks,
> Karl.
>  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/630d97b1/attachment.html 

More information about the Rspec-devel mailing list