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”

NerdDinner solution with MSTests re-written as NUnit Tests and WatiN Automated UI Tests

CI Factory modified solution that I used for creating a CI Build from scratch

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
    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)  
  Dim testResult as Integer
  Dim newHeading as Integer
  Dim targetHeading as Integer
  Dim currentHeading as Integer
  'Test TestHeading
  DebugPrintLine "TestHeading Tests"
  SetTargetHeading newHeading
  If (testResult<>0) Then
    DebugPrintLine "Test 1 Failed"
    DebugPrintLine "Test 1 Passed"
  End If
  SetTargetHeading newHeading
  If (testResult<>-1) Then
    DebugPrintLine "Test 2 Failed"
    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.

Testing without a testing framework

by Mike Linnen 19. May 2005 06:53
Testing without a testing framework

I have been doing a lot of Unit Testing in my day job using NUnit as the framework. I find writing code to test code is very interesting and makes my coding efforts less bug prone. However in my off time I often mess around with non .Net programming projects and I miss the ability to write test code in these projects. Well it is not too hard to follow the same sort of unit testing practices when you do not have a testing framework in place.

Just recently I was writing some BX24 code for a robotic project. I needed to create some conversion procedures to go from a Byte/Integer to a String and a String to a Byte/Integer. How would I determine that my new procedures would work as designed? Certainly I could not rely on the production robot code to test the conversion procedure.

The BX24 programming language has the concept of projects and source modules. A project is nothing more than a collection of source modules. One of the source modules must be the main entry point of the project for starting execution. This concept allows me to simply create test projects that are designed to test a single source module.

So I moved my conversion procedures into a Conversion Module and made a Conversion Test project. Then I proceeded to write test code in the main module of the Conversion Test project to exercise the Conversion Module. I now had unit tests that exercised the outer bounds of the Conversion Module. I proceeded to fix bugs in the Conversion Module until all tests passed.

Of course without a framework I did not have the nice GUI with Red/Green lights to tell me a test passed or failed but it sure did help me determine if my module was fully functional or not. So if you have a programming project that does not have a nice unit testing harness but your IDE supports module level programming you to can use the above techniques to write bug free code.

Tags: ,


About the author

Mike Linnen

Software Engineer specializing in Microsoft Technologies

Month List