About Me

Training

Nothin But .Net Developer Bootcamp

Navigation

Search

Categories

On this page

Screencast – Getting Started With Machine.Specifications
More new conventions for how I organize my tests!!

Archive

Blogroll

 Agile Developer Venkat's Blog
 Ayende @ Blog
 B#
 Barry Gervin's Software Architecture Perspectives
 Boy Meets World
 Brad Abrams
 Canadian Developers
 Christopher Steen
 Claritude Software News
 Clemens Vasters: Enterprise Development and Alien Abductions
 Coding Horror
 Coding in an Igloo
 Dare Obasanjo aka Carnage4Life
 Darrell Norton's Blog [MVP]
 David Hayden [MVP C#]
 Don Box's Spoutlet
 Eric Gunnerson's C# Compendium
 EZWeb guy: Jeffrey Palermo [C# MVP]
 Fear and Loathing
 Generalities & Details: Adventures in the High-tech Underbelly
 Greg Young [MVP]
 Greg's Cool [Insert Clever Name] of the Day
 IanG on Tap
 Ingo Rammer's Weblog
 ISerializable - Roy Osherove's Blog
 James Kovacs' Weblog
 Jason Haley
 Jean-Luc David
 Jeremy D. Miller -- The Shade Tree Developer
 JetBrains .NET Tools Blog
 Jimmy Nilsson's weblog
 John Bristowe's Weblog
 John Papa [MVP C#]
 Jon Skeet's Coding Blog
 JonGalloway.ToString()
 Jump the Fence or Walk Around
 Lambda the Ultimate - Programming Languages Weblog
 Larkware News
 Lutz Roeder
 Marquee de Sells: Chris's insight outlet
 Martin Fowler's Bliki
 Mike Nichols - SonOfNun Technology
 MSDN Magazine - .NET Matters
 MSDN Magazine - All Articles
 OdeToCode Blogs
 Onion Blog
 Planet TW
 Raymond Lewallen [MVP]
 Rockford Lhotka
 RodMan's Corner
 Roger Johansson's blog
 Sahil Malik - blah.winsmarts.com
 Sam Gentile's Blog
 Scott Bellware [MVP]
 Scott Hanselman's Computer Zen
 ScottGu's Blog
 secretGeek
 Service Station, by Aaron Skonnard
 Signum sine tinnitu--by Guy Kawasaki
 Stephen Toub
 Steve Eichert's Blog
 Steven Rockarts
 The Blog Ride
 The Coding Hillbilly
 The Daily WTF
 TheServerSide.net: News
 Tim Gifford
 Vance Morrison's Weblog
 you've been HAACKED

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

RSS 2.0 | Atom 1.0 | CDF

Send mail to the author(s) E-mail

Total Posts: 519
This Year: 28
This Month: 0
This Week: 0
Comments: 1589

 Tuesday, May 11, 2010
Tuesday, May 11, 2010 2:00:00 PM (Mountain Standard Time, UTC-07:00) ( BDD | ScreenCasts | Training )

In this screencast I walkthrough getting started writing unit tests using the Machine.Specifications testing library (the developwithpassion fork of this project).

Along with introducing the basics of using Machine.Specifications, I also make a point of demonstrating some of the customizations to the library that exist only in the fork which contains all of the functionality that I ported from developwithpassion.bdd.

Some of the things covered in this screencast are as follows:

-Cloning the developwithpassion fork of Machine.Specifications
-Packaging a binary from the source
-Structure of a unit test in Machine.Specifications
-AAA style testing (very brief)
-DevelopWithPassion specific extensions to the Machine.Specifications library

This is another video in the prep series for the Nothin But .Net series of classes; if you are considering taking the class or are a person who has registered for one of the upcoming course, consider this material absolutely essential to know.

As always, any feedback that can be made on the video would be greatly appreciated. In this video I decided to omit the actual camera feed that has accompanied the last couple of videos (if you miss it, please let me know).

Along with good critical feedback on the video, if you could also submit any suggestions for things that you may want to see/hear about in the future, please let me know.

In the meantime, Develop With Passion!!!

Video: Introducing Machine.Specifications

 

+++On a pure technical note, I ported all of the screencasts from Windows Azure storage to a regular Vimeo account (much cheaper and far less issues with respect to publishing from screenflow).

Comments [3] | | # 
 Monday, February 16, 2009
Monday, February 16, 2009 8:00:00 AM (Mountain Standard Time, UTC-07:00) ( BDD | C Sharp )

As the current project I am on is getting fairly large now, I just recently switched around the way I organize my tests. Here is a sample concern pulled from a main class in my application (smart client based):

public class ApplicationControllerSpecs

{

    public abstract class concern : observations_for_a_sut_with_a_contract<IApplicationController, ApplicationController>

    {

        protected IApplicationShellView shell_presenter;

    }

 

    [Concern(typeof (ApplicationController))]

    public class when_starting_up : concern

    {

        context c = () =>

        {

            application_shell = the_dependency<IApplicationShellPresenter>();

            start_all_modules = the_dependency<IStartAllModules>();

            event_aggregator = the_dependency<IEventAggregator>();

        };

 

        because b = () =>

            sut.start();

 

        it should_start_the_application_shell = () =>

              application_shell.received(x => x.start());

 

        it should_start_all_of_the_application_modules = () =>

             start_all_modules.received(x => x.run());

 

        it should_register_itself_as_a_listener_with_the_event_aggregator = () =>

            event_aggregator.received(x => x.register_listener(sut));

 

        static IApplicationShellPresenter application_shell;

        static IStartAllModules start_all_modules;

        static IEventAggregator event_aggregator;

    }

 

}

Notice how at the top I am now creating a container class which is named {SUT}specs:

public class ApplicationControllerSpecs

All of the concerns for the ApplicationController will be housed inside this class. From an organizational perspective I can now have a superclass for all of my concerns for a particular SUT named concern:

public abstract class concern : observations_for_a_sut_with_a_contract<IApplicationController, ApplicationController>

{

    protected IApplicationShellView shell_presenter;

}

Before, I would place my concerns directly at the root of the file (not nested inside a container class), this meant that when I went to derive a concern from a base concern, I would have to filter through a big ReSharper list of all of the base test classes in the solution that started with the word concern. Because I was following a convention of “concern_for_[sut]”, I would see more than I wanted. Now when I am inside of a container class and am writing a concern that I want to derive from its parent concern,typing con followed by CTRL-SPACE will only give me a very small set of options. I also don’t need to come up with a fancy name for the initial concern superclass. I can just call it concern. Each *Specs file in my current application follows this convention, and each one has an initial superclass named concern. You don’t need the superclass, I just find it a convenient place to put fields etc that can often crowd up the test, common results etc.

Develop With Passion!!

Comments [9] | | #