using MbUnit.Framework;
using Rhino.Mocks;

namespace Suvius.Applications.LoveDoctor.Tests
{
    public class CritterFixationFixture
    {
        private ISpeciesSelectorPresenterView view;
        private MockRepository mocks;
        private SpeciesSelectorPresenter presenter;

        [ SetUp ]
        public void SetUp( )
        {
            mocks = new MockRepository( );
            view = mocks.DynamicMock<ISpeciesSelectorPresenterView>( );
            presenter = new SpeciesSelectorPresenter( view );
        }

        [ Test ]
        public void Should_initialize_view_with_list_of_projects( )
        {
            using ( mocks.Record( ) )
            {
                view.LoadCritters( );
            }
            using ( mocks.Playback( ) )
            {
                presenter.InitializeView( );
            }
        }
    }

    public class SpeciesSelectorPresenter
    {
        private readonly ISpeciesSelectorPresenterView _view;

        public SpeciesSelectorPresenter( ISpeciesSelectorPresenterView view )
        {
            _view = view;
        }

        public void InitializeView()
        {
        }
    }

    public interface ISpeciesSelectorPresenterView
    {
        void LoadCritters( );
    }
}

How's THAT for throwing you into the fray? I can see all of you now going, "whoa, there, Coding Hillbilly! I ain't e'en got me a cuppa joe yet, buddy." Sorry, folks, that's how I roll. I think slow and act fast. You gotta keep up.

The test above sets up an expectation that LoadCritters will be called on the View when we called Presenter.InitializeView. In actual fact, this isn't being done. So here's the poser: why does this test pass?

All right, I'll tell ya because I like your look. And I don't want to risk any of you actually cutting and pasting that into an IDE and coming up with some cut 'n paste error I made. Plus I gave you a hint in the post title.

The test isn't actually passing. When it hits view.LoadCritters, it fails silently and kicks out of the test completely. The reason bein' SetUp isn't being called. The reason for *that* bein' I forgot the [ TestFixture ] attribute on the class itself.

Now as to the question on why the test doesn't fail with a null reference exception: That's an easy answer. I have no idea. If you add the [ TestFixture ] attribute and comment out the code that creates the view, it does fail with the expected exception.

So I'll leave that to my loyal and, I pray, generous readers.

Kyle the Deferred