Karl,
If your context really is the Presenter, then you'd do well to spec
the Presenter in isolation. You'll want to spec the behaviour of the
view as well, but not in this context, it seems.
To that end, the last example you provided looks the healthiest to me:
> [Test]
> public void ShouldAllowNewAccountToBeCreated() {
> int numberOfAccounts = myAccountsModel.Accounts;
>>> /*** Change the View invoke to Presenter ***/
> myPresenter.CreateNewAccountEventRaised();
>>> Assert.AreEqual(numberOfAccounts + 1, myAccountsModel.Accounts);
> }
>
But I'm still a little spooked by the
myPresenter.CreateNewAccountEventRaised() call. Is that a method that
gets invoked in the standard operations of the Presenter? It looks
like a private method, based on the name, and specifications tend to
work better when they are more coarse-grained, and focussed on the
public methods of your object. Again, please forgive my naiveity about
your framework.
> 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.
I might differ from others on this point - but unless your tests are
calling some external API, and taking waaaaaay too long to execute
(and there are plenty of reasons this is bad), a slight performance
drag is no problem, or at least, not something to water your tests
down over.
One final consideration - your specification framework should reward
you for writing specs first, and then coding to meet those specs. That
is the main advantage I find of RSpec over Test::Unit in Ruby. While
it is possible to use the both specs and tests to exercise the same
code in the same ways, I find that I write specs first, and think of
them as specifications, while I tend to write unit tests after or
concurrently with writing the unit code itself. Those unit tests are
usually more tied to the internals of the units, than specs are -
precisely because specifications are speculative - they tell me what
I'd *like* the API to be, before it even exists.
So take care that your spec implementation rewards spec-first
behaviour. Otherwise you may as well be writing unit tests (which I
find quite handy, but in a different way from specs).
Best,
Chris