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
by Mike Linnen
17. November 2005 21:50
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.
by Mike Linnen
20. October 2005 01:25
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.
by Mike Linnen
19. May 2005 06:53
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.