Due to requests, I am making available my Collection Templates. There is one thing to note about this template. When you do a Project > Add Class, and choose Collection Class, the class must be named [Object]Collection (name must end in the word collection).
The template creates a generic collection with accessors and whatnot for a collection of type [Object] . In the example above, a collection of 'Book's would be generated. Enjoy.
Update: These templates are for VS.Net 2k3 and need to be edited for the origional release of VS.Net. Edited the .vsz file and change the line
Wizard=VSWiszrd.VSWizardEngine.7.1
to
Wizard=VSWiszrd.VSWizardEngine.7.0
This applies to my NUnit templates as well.
One of the biggest problems to writing tests (first), is all the redundancy in setting up the test class.Unfortunately NUnit does not have a built in answer to this problem. So to that end, I created several template files to generate these test classes for me when when I do a Project>Add Class from within Visual Studio.Net. I am making my templates available here in hopes that it will help encourage you to write your tests first. Just unzip the download into your VC# install directory (Mine is located at “C:\Program Files\Microsoft Visual Studio .NET 2003\VC#”). Enjoy.
I have also created several other templates, of which I use predominantly: New Class, New Collection. If there is interest, I can post these as well.
After a long while working with NUnit, and the NUnit team not wanting my additions, I feel that this is my best outlet for a simple update that covers a missing core assumption in the testing framework. Currently the framework supports Assert.AreEqual() on the core data types, but leaves out support for collections and lists, really anything that is of IEnumerable. So i have written a new class full of tests, and extended the NUnit framework to support Assert.AreEqual(IEnumerable, IEnumerable).
Download Assert.cs and EnumerableEqualsFuxture.cs.
Changes to Assert.cs, add the following 3 functions:
static private void AreEqual(IEnumerator expected, IEnumerator actual) {
Assert.AreEqual(expected, actual, string.Empty) ;
}
static private void AreEqual(IEnumerator expected, IEnumerator actual, string message) {
int actualCount = 0, expectedCount = 0;
expected.Reset();
actual.Reset();
while (expected.MoveNext()) { expectedCount++; }
while (actual.MoveNext()) { actualCount++ ; }
Assert.AreEqual(expectedCount, actualCount, "Enumerable objects, counts are not equal.");
expected.Reset();
actual.Reset();
actualCount = 0;
while (expected.MoveNext() && actual.MoveNext()) {
actualCount++;
Assert.AreEqual(expected.Current, actual.Current, string.Format( "Enumerable objects, {0}{1} item:{2}", actualCount, NumberEnding(actualCount), message));
}
}
static private string NumberEnding(int number) {
switch (number % 10 ) {
case 1 : return "st" ;
case 2 : return "nd" ;
case 3 : return "rd" ;
default : return "th" ;
}
}
Also add the commented section to ObjectEquals
static private bool ObjectsEqual(Object expected, Object actual) {
//add starts here for IEnumerable support
if ((expected is IEnumerable) && !(expected is string) &&
(actual is IEnumerable) && !(actual is string)) {
if (expected.GetType().Equals(actual.GetType())) {
Assert.AreEqual(((IEnumerable)expected).GetEnumerator(),
((IEnumerable)actual).GetEnumerator());
return true;
}
}
//add ends here for IEnumerable support
if (IsNumericType(expected) && IsNumericType(actual)) {
string = expected.ToString();
string = actual.ToString();
return sExpected.Equals(sActual);
}
return expected.Equals(actual);
}
Now assert away on your collections and lists.
Hello .Net land.
I have been doing .Net development since the second beta. I participated in the Early Adopter program and created the first .Net web application and accompanying web services for GlaxoSmithKline.
I am a currently a member of the Piedmont Triad .Net user Group - PTNUG, where I plan to give several talks about the application of eXtreme Programming in the .Net world.
I am currently a MCT and available for your training needs, and can be reached thru the contact form.
Ideal Pair StationsOne of the biggest aspects of
eXtreme Programming (XP) that is usually rejected is that of
Pair Programming. This usually due to pre-conceived notions by the developers or poor pair station design that does not actively engage both developers. Pre-conceived notions are hard to eliminate, but providing a developer friendly pair environment will help in adoption of pair programming, despite these notions.
The hardest obstacle to overcome is to keep both members of the pair actively engaged during the entire coding session. There are many different approaches that you can take to keep the developers active. Having a manager or coach baby-sit them, requiring driver changes every 10 minutes, or “You must pair” rules only make developers hate the practice of pair programming. In most cases all that is needed is several environmental changes that will facilitate developer engagement and interaction, and improved adoption of the practice.
Get out of the corner.One of the hardest environments to pair program in is the common office setup with the computer and monitor tucked away in the corner to increase desk space. This creates several problems, as usually only one developer is ever actually engaged in the current coding session. The partner is stuck looking over the code monkeys shoulder, if they are even paying attention to what is being written at all. In most cases, the partner will open the book to appear as if they are looking up something relevant to the current coding task, leaving the monkey to do the work. This usually results in double the work cost for a project, and should be avoided at all costs.
One of the simplest, most effective changes to get both developers active is to replace the corner desk with a standard 6x2 table; folding tables work well. Place the computer in the middle of the table. This allows both developers to sit at the table, to be closer to the action on the monitor, and to easily switch who is driving by only moving the keyboard and mouse. Both developers can always see the monitor, and no one feels as if they are being watched, which is a natural distraction.
Use technology to your advantage.Once you are out of the corner, use the cheap cost of technology to your advantage. Most computers sold today have at least one USB hub embedded onto the motherboard. This allows the user to easily add more input devices than the standard PS2 keyboard and mouse. Attach a second USB keyboard and mouse. Most modern operating systems, including Windows XP and Windows 2003 Server, support having two active keyboards and mice. Now both partners in the pair can actively drive, and are not prone to the ‘open book and fake pairing syndrome’. A word of caution here, as it does take a little time to fully realize the power developers have when that can change what the other is working on without directed intent, and to overcome their natural tendency to start typing or clicking while their partner is doing so.
Now that both members of the pairs can actively drive, enable them both to more easily see what they are doing. Provide a second monitor and place one in front of each developer. The simplest way of doing this is to buy a video feed splitter and multiplex the output from the computer to both of the monitors. This requires no internal hardware/operating system reconfigurations, and is fairly simple to do. A second way of providing two video feeds is to replace your current video card with one that supports multiple outputs, or adding a second video card. In either case, you need to configure your operating system to mirror the video output to both monitors, so that each pair is seeing the same thing on the screen. Extended desktops can be useful in some pair debugging sessions, but more times than not, you want both developers to see the same thing. As such, setting up the dual video card systems with extended desktops is not recommended.
At this point, both developers in the pair are in front of their own console, and can actively participate in what is happening in the coding session. This not only improves the partners understanding of what is going on, but facilitates the partner’s ability to inject when they have issue with what is being developed.
In PracticeOn my last engagement, we experimented with the concepts and practices of XP during a major release. Once that release was over, the team as a whole accepted XP, and we moved to that development style for the next release. This included adoption the pair programming model. Before adopting XP, we had a center room that held four developer cubes, each with corner computers. After several days of fighting the corners, minimal creature space, and the ill comfort of leaning over shoulders, it was time to take action and improve the development experience.
First we disassembled the cubicles, leaving only the desk that was attached to the wall. This took about two hours to disassemble all four cubes. (Total cost, four man hours and a little sweat.) We removed the dividers creating a very open room. This helped to promote discussion between pairs when questions about the existing system arose, or when pairs got stuck on solving the issue at hand. Next we placed the original computer towers on the middle of the desk, and attached a second USB keyboard and mouse. (Total cost, $10 a keyboard, $20 a mouse, per station.) The next step was to add a new monitor and video splitter to each station. We originally had 21” monitors on each of the dev boxes, and decided to add a second 21” for the pair. (Total cost, $250 a monitor, $40 a splitter with cables, per station.) We now had 4 pair stations in the room, and added an extra table out of one of out conference rooms. At a total cost of $320 per station, we now had a very conductive XP pair programming environment.
After only a few weeks of using this new environment, productivity on the project increased, and everyone’s knowledge transfer more than doubled from before when we were all in separate offices and cubes. After a few months of using this environment, it was noticeable that everyone’s overall knowledge of the application had increased beyond what normally would have occurred in the same amount of time in separated environments. This allowed us to have more than the original developer fixing bugs in defined project areas, and enabled feature requests to be implemented in a shorter period of time. After a year of being in this environment, there was no question that we had earned back several times over the initial $1300 we invested to create the ideal pair development environment. Our bug counts for each iteration (two weeks) had reduced about 38% from the pre-pair days, and each successive iteration was seeing less and less new bugs entererd into the bug tracking system.
Increasing the engagement time of each developer is required to successfully adopt the practice of pair programming. This leads to increased knowledge transfer throughout your development team, overall better communication, and more productive coding sessions. And to do so, it can be as simple as changing the environment that pair programmers work in.