Wow….nobody is in Oren’s presentation.  They must be getting their heads exploded in JP’s.

Wow…Oren just said he posts at his blog “every now and then”.

Interaction based testing does have any state to check, so you must test the collaborations (complex or simple) between objects.  Objects don’t work in isolation.  Mocking dependencies allows us to test the main code in isolation.  You can accomplish this with Mocks, Stubs and Fakes.

• Fakes:  working implementation, but not a useful one (a DAL that returns from a dataset rather than a database)
• Stub:  empty implementation which may optionally record the calls made to it
• Mock:  pre-programmed for a certain scenario, verify that the scenario was executed properly.

And the maintenance guy steps in to stand right in front of the screen to shut off two lights.  According to Oren that was an integration test.

Testing that an SMS message was sent:

• State Based: Assert.IsTrue(webService.SentSMS);
• Interation Based:  Expect.Call(webService.SendSMS(“1234”, “hi”));

Interaction Based Testing

• Advantages

• Helps test in isolation

• Handles complex scenarios better
• Encourage best practices* Disadvantages

Steps of mocking

1. Create Mock
2. Set Expectations
3. Run Code
4. Verify Results
5. Pass/Fail Test

Now we get to see Oren code.  He’s an MbUnit guy it looks like.  Definitely TDD.  Okay…this is how you use ReSharper to make you demo fly.  Roy Osherove comments that Oren’s coding with ReSharper like there’s UI Automation going on.

Oren uses a ReSharper Live Template of “nm” for  creating a mock object.  What’s wrong with “cm“?  Does he have something against the letter “c”?

Hot Agilista update….I think they’re stalking me.  Everywhere I am they are.

Straight Mocks don’t allow you to do anything that you don’t set expectations for.

Constraints:

• LastCall.Constraints(Is.Equal(“1234”), Text.Contains(“new password: “));

SetupResult:

• SetupResult.For(userRepository.GetByUserName(“sally”)).Return(user);

Interesting code formatting for try…catch blocks.  I’ve never seen the catch on the closing chicken-lip line.

try

{

…

} catch (Exception e)

{

…

}

Oren is a ReSharper ANIMAL.  He’s the Israeli JP Boodhoo….but about four times as big physically.

Oren recommends “Working Effectively with Legacy Code“ because it has a lot of good ways to construct your tests.

[assembly: InternalsVisibleTo(Rhino.Mocks.RhinoMocks.StrongName)] – can expose internal items for mocking

Hand-in-hand with mocking

• Dependency Injection
• Inversion of Control
• Programming to Interfaces
• Separation of Concerns

Don’t fall into Test Paralysis.  Let your tests have room for change.  Don’t specify too much in your tests because it can lock the test which can lock your code.

Make sure your tests are explicit in what they test.

Use the Rhino .Message(…) syntax to help document your tests.

Don’t mock

• anything you don’t own the interface for
• small granularity code