Tools for Agile Development presentation materials

by Mike Linnen 17. May 2009 18:19

In this post you will find my PowerPoint and source code I used for my presentation at Charlotte Alt.Net May meeting.  I had a good time presenting this to the group even though it was very broad and shallow.  I covered the basis on why you want to leverage tools and practices in a Lean Agile environment.  I got into topics like Source Control, Unit Testing, Mocking, Continuous Integration and Automated UI Testing.  Each of these topics could have been an entire 1 hour presentation on its own. 

Here are the links to the tools that I talked about in the presentation:

Power Point “Tools for Agile Development: A Developer’s Perspective” http://www.protosystem.net/downloads/ToolsForAgileCharlotteAlt.Net/ToolsForAgile.ppt

NerdDinner solution with MSTests re-written as NUnit Tests and WatiN Automated UI Tests http://www.protosystem.net/downloads/ToolsForAgileCharlotteAlt.Net/NerdDinner_ToolsForAgileDev.zip

CI Factory modified solution that I used for creating a CI Build from scratch http://www.protosystem.net/downloads/ToolsForAgileCharlotteAlt.Net/CIFactory_ToolsForAgileDev.zip

TFS Build reports partial fail even when all tests passed

by Mike Linnen 8. January 2009 09:33

I ran into a strange issue today when I was trying to figure out why my TFS Build was reporting that the build was partially successful even though every test was passing.  The normal build report really did not give any good reason why it was partially successful other than the fact that it was something related to the unit tests (I am using MS Test in this case).  So I cracked open the build log and peeled through the entries.  I noticed that when the code coverage was attempting to instrument the assemblies it reported that several of the assemblies could not be located.  Then I remembered I did some refactoring and I renamed and consolidated some assemblies. 

Well that should be an easy fix all I had to do was remove these assemblies from the test run config in the Code Coverage section.  So I opened up the LocalTestRun.testrunconfig file in Visual Studio 2008 and selected the Code Coverage section to make my changes.  As soon as I did this the config editor closed down (crashed).  Wow that was weird I never saw that before.  Hmmm I wonder what it could be.  Well here is what I did to try and locate the issue.

  1. Perhaps the Test Run Config file needs to be checked out of source control for write access.  Nope that wasn't it.
  2. Well if I cant edit it in VS 2008 then I might as well try notepad.  I removed the offending assemblies using notepad in the LocalTestRun.testrunconfig.  However once I opened up the Test Run Config editor and selected the Code Coverage the editor still crashed.
  3. Perhaps I malformed the Test Run Config xml file.  So I opened it up again in notepad and the XML looked fine.  Besides if this XML was malformed I don't think the Test Run Config editor would not open at all.
  4. Consult almighty search engine.  Wow look what I found http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=391255 and it was only reported 2 days ago.

So to be sure that I got the Test Run Config file right I removed my Database project from my solution made my edits for Code Coverage in the Test Run Config editor, then added the database project back into the solution. 

After fixing the Test Run Config file my build ran successfully.

VS.Net 2005 and NUnit

by Mike Linnen 17. November 2005 21:50
VS.Net 2005 and NUnit

Well I have been looking at VS.Net 2005 some since it has released.  I wanted to try out some of the new features.  Well I am pretty attached to using NUnit so once I got a little bit of code going in VS.Net 2005 I decided it was time to try NUnit.  Fortunately there is a new iteration release of NUnit (2.2.3) that works with VS.Net 2005. 

So I downloaded it and wrote my first test like I always do.  Create a test project, add a reference to NUnit, add a new class, put a TestFixture attribute on the class, and add a public method that returns void that also has the Test attribute. I then proceeded to fire up NUnit GUI and run the test. However the test I wrote does not show up in the GUI. I fiddled around with the test code for a while and I even downloade the NUnit source code to try and figure out why my test was not seen by NUnit. Well after about 30 minutes of messing around I realized that when you add a new class to VS.Net 2005 project it looks like the following

using System;
using System.Collections.Generic;
using System.Text;
namespace ProtoSystem.Scrum.Business.Tests
{   
   class Class1
   {
   }
}
I never noticed the fact that public does not appear before the keyword class. So the test class could not be seen by NUnit.

Another Test example for the BX24

by Mike Linnen 20. October 2005 01:25
Another Test example for the BX24

A previous post I explained how simple it is to test your code even though you might not have a fancy test framework like NUnit.  In this post I am going to give another example of what I did to tackle a robot navigation problem and fully testing it without actually running the code in a real robot.  My point here is that it is a good practice to write test code to test sub modules to simulate all possible scenarios that would be tough to do in the real robot.

So here is the problem:

I have a compass module that outputs a heading value that equates to 0-359 degrees. I needed a module that when given a target heading and a current heading it could return the differance between the two in degrees. The return heading difference would range from -180 to 180 degrees. This return value could be processed further to determine which direction the robot needed to turn to reach the target heading. A negative heading ment to turn left and a positive number would mean turn right.

So my approach was to first identify a list of target and current headings and what I would expect the return value would be for these input parameters. I did this for 17 different scenarios. I placed the values in a spread sheet and analyzed the pattern that emerged. I took this pattern and coded a simple class (module) that would impliment the pattern.

Here is the method of the class:

Public Function GetHeadingDifference(currentHeading as Integer) As Integer
  ' Returns the following
  ' -180 to + 180
  ' Negative number means the robot would have to turn to the left to get closer 
  ' to the targetHeading
  ' Uses module variable targetHeading
  
  Dim targetMinusCurrent as Integer
  targetMinusCurrent = targetHeading - currentHeading
  
  If (targetMinusCurrent<181) And (targetMinusCurrent>-181) Then
    GetHeadingDifference=targetMinusCurrent
    Exit Function
  End If
  
  If (targetMinusCurrent<-180) Then
    GetHeadingDifference=360 - ABS(targetMinusCurrent)
    Exit Function
  End If
    GetHeadingDifference=(360-ABS(targetMinusCurrent)) * (-1)
End Function

I then created another test class (module) that would call the navigation module and pass in the 17 scenarios and validate the return heading.

Public Sub Main()
  '.......... Test code ..........
  'This needs to be done only once per program, or when you want to change the baud
  Call UARTsetup(3, 19200)  
  InitializeNavigation
  Dim testResult as Integer
  Dim newHeading as Integer
  Dim targetHeading as Integer
  Dim currentHeading as Integer
  
  '****************************************
  'Test TestHeading
  '****************************************
  DebugPrintLine "TestHeading Tests"
  newHeading=180
  currentHeading=180
  SetTargetHeading newHeading
  testResult=TestHeading(currentHeading)
  If (testResult<>0) Then
    DebugPrintLine "Test 1 Failed"
  Else
    DebugPrintLine "Test 1 Passed"
  End If
  newHeading=180
  currentHeading=183
  SetTargetHeading newHeading
  testResult=TestHeading(currentHeading)
  If (testResult<>-1) Then
    DebugPrintLine "Test 2 Failed"
  Else
    DebugPrintLine "Test 2 Passed"
  End If
........... more test code omitted for clarity 
End Sub 

I used the 17 scenaros that I layed out on the spread sheet to prove out my logic. Since the module is fully tested based on these scenarios I have complete confidence that the module will work when it is included in the main robot code project.

About the author

Mike Linnen

Software Engineer specializing in Microsoft Technologies

Month List