There is a nice library called PS-Eventing that makes the event handling a whole lot cleaner and generally a nicer experience. This post with the plugin is not a smaller and doesnt really do any else other than the last post except cleanly deregister the event, but is much more user friendly.
I think i will also post my code on gisthub as I am not and have not been at my real machine for so long… i miss it… sorry.
Heres the link : http://gist.github.com/632749
Category Archives: TDD
Auto test – Thanks Powershell
Im doing some funky Nunit stuff* at the moment and sometimes the ReSharper or TD.Net runner wont pick up my inner fixtures, the console runner however runs them just fine. Here is a PS script to have auto test running on build:
$Script:initialdir = “C:\myroot\”
$fsw = new-object system.io.filesystemwatcher
$fsw.Path = “c:\mysln\myproj\Bin\”
$fsw.EnableRaisingEvents = $true
$action = {
$filter = “*Tests*.dll”
$file = $Event.SourceEventArgs.FullPath
if($file -like $filter)
{
$nunit = “C:\3rdParty\NUnit-2.5.2\nunit-console”
$currentdate = get-date -format g
write-Host “Running Tests on $file $currentdate” -ForegroundColor Yellow
&”$nunit” /xml:$_.Name-testresult.xml $file
if($LastExitCode -ne 0)
{
WRITE-HOST “Test have failed for $file”-ForegroundColor RED
}
else
{
WRITE-HOST “Test have passed for $file”-ForegroundColor GREEN
}
#$null = Remove-Event $_.EventIdentifier
}
}
Register-ObjectEvent -InputObject $fsw -EventName Changed “FileChanged” -Action $action
Register-ObjectEvent -InputObject $fsw -EventName Created “FileCreated” -Action $action
Note that you will either have to explicit unregister your event handlers or kill powershell to get rid of the handlers. Cancel the watcher by hitting ctrl+c and then Unregister by runnning these lines
unregister-event “FileCreated”
unregister-event “FileChanged”
*The stuff we are doing is to do with inheritance and inner test fixtures to give us a BDD experience without the drama of the BDD frameworks, that personally I still dont like. We are still a fair way off the TDD experience of the Ruby kids.
Arguments in Stubs and mocks
Below is an informal email to work mates. Please note I am not the boss, I am a lowly contractor at the bottom of the heap, The devs I work with have a refreshingly open communication channel and I tend to have a bit more experience in Testing/TDD
*****
Hey Guys
I think I have unfortunately let some bad habits of mine slip over to you guys.
Some basic rules of thumb:
-Stubs should be used by default to isolate dependencies, use mocks when you are mandating that the SUT is incorrect if it does not interact with the given dependency.
-I will often declare in a test method set up the class level dependency to be a mock (with associated verify in the tear down), however that does not need to have expectations. You can always use the stub method on a mock, meaning failure to call that method will not fail the test.
-Use correct arguments and return values. Returning null and using the .IgnoreArguments() method should be last resorts and are generally a sign (if it is my code) of laziness or haste. Don’t do it unless it actually makes sense for the test.
-When returning null from a stub or mock the SUT should be handling it properly. I.e. what if that dependency actually did pass back a null? Is that even valid? Should we be handling it?
The major problem I find is the ignore argument method, I abuse it far too much when mocking, and I see it creeping it others work (not just ours but external code too!). Note: Ignore Arguments on stubs is not so bad, as a stub should not fail a test
RhinoMocks has the ability to specify argument placeholders that do not have to be the exact reference type that is being used e.g.:
timesheetService.
Mock(s => s.SaveNewTimesheet(
Arg.Is.Equal(creationDto)
))
.Return(new TimesheetDetailsDto());
Which is much better than:
timesheetService.
Mock(s => s.SaveNewTimesheet(null))
.IgnoreArguments()
.Return(null);
Be sure to override the equals method to accurately reflect the equality tho, otherwise the default of reference equality will still cause the test to fail!
Manning Book Reviews
Thought i’d let you guys know of some books i have been reading that are pretty good, They are all from Manning which I am really starting to like that publisher more and more.
JQuery In Action: Within about 90 minutes of reading this book you will understand the fundamentals of jQuery and be ready to do basic, but powerful, jQuery code. If you are using javascript natively seriously consider switching to jQuery and get this book. jQuery also has a test framework (QUnit) and a great suite of UI plugins (jQuery UI)
Art Of Unit Testing: Easily the best unit testing book I have read (and I have read a few). Great for newbies and those still getting to grips with how to test anything more than the most trivial of examples. It is the book i would recommend to people looking to learn to do TDD well. Note the examples are in C# but they really dont require indepth knowledge of .Net, in the same way all the other books are in java and I havent written a line of a coffee flavoured code in a decade. In saying that the tools are all .Net based but i am sure there are Python, Ruby and Java equivilents avaliable for most.
NHibernate in Action: Pretty much the same as the Hibernate book but shows all the .Net stuff you can do. its also a bit more up to date that the original Hibernate book (which has since had a second release). .Net devs nusing NH need* this book.
IronPython in Action: not a bad book… it does exactly what it intends, it teaches .Net devs about python on the CLR. The question is: Do you care? For me it was something of interest, i doubt I’ll ever use it in production. As a side note for the .Net kids i think the path of C# => Boo => Python =>Ruby is the one to take for the typical C# developer**. It keeps the “barrier to entry” low for the next step so you are picking up one new thing at a time (ie new syntax, dynamic language contrainst, DSLs and other scripty weirdness) and by the end of the process you have 4 languages under your belt in about the same time it would take to do the C# => Ruby jump.
that’s all
Rhys
*OK no one needs anything, especially as the NH doc a pretty good, but you will be severely hindered without it.
** VB.Net devs; you know you will never learn another language, you have had years to do so!
Real World Test Driven Development: Unit Testing Enterprise Solutions
Join us at the Perth .NET Community of Practice, Thursday March 5th to hear Rhys Campbell present on the essentials of TDD and how encourages good software design as opposed to just having tests. Rhys will cover the differences between unit, acceptance and integration tests, why conventional unit test examples often do not work in the real world, what to test and what to mock, automating your tests, coding examples of how to use Mocks, Stubs, Fakes, Dummies and Spies… what are they and how do they help me.
TOPIC: Real World TDD with Rhys Campbell
DATE: Thursday, March 5th, 5:30pm
VENUE: Excom, Ground Floor, 23 Barrack Street, Perth
COST: Free. All welcome
Rhys Campbell is a software developer currently contracting in Perth, WA. He recently returned from London, where he has been active in the .NET community, attending and speaking at the 2008 Seattle and London Alt.NET Open Spaces. Rhys is interested in design, architecture, patterns and bringing best practices from other communities to .NET. Rhys is a director of ArtemisWest.
There will be door prizes of a ReSharper license (courtesy of JetBrains) and T-Shirts (courtesy of Redgate).
Mocks v Stubs
I am sure you have read this, but for me a couple of weeks ago this was what I needed:
http://martinfowler.com/articles/mocksArentStubs.html
specifically:
The Difference Between Mocks And Stubs
Using mocks when you don’t care if the interaction occurs mean you are writing brittle tests that are not testing what they should be. Stubs are more appropriate in this situation… sometimes I forget and go mock mental. Naughty!
Rhys Campbell 