# Friday, July 08, 2005
Obfuscation Blog on MSDN

PreEmptive Solutions, the creaters of the Dotfuscator, have a new blog and it's on MSDN.

Be sure to send them all of your great questions about how and why to obfuscate. The Dotfuscator Team loves getting good questions...



Friday, July 08, 2005 6:31:58 PM (GMT Standard Time, UTC+00:00)  #  Comments [0] 

Bill Wagner WebCast on Advanced DataBinding in .NET 2.0 Smartclients

Bill Wagner, my business partner and author of Effective C#, is doing a web cast on Monday, July 11, at 2:00 Eastern Time.



Friday, July 08, 2005 6:11:21 PM (GMT Standard Time, UTC+00:00)  #  Comments [0] 

# Monday, June 13, 2005
Drew Robbins: The Dancing DE

Update: I've cleaned up the video - see the new link below...

I did a lot of fun things last week at TechEd. One of those was a Central Region Influentials party at the NASCAR Cafe. You learn a lot of fun things about people at these parties like the fact that Drew Robbins (the Developer Evangelist from the Great Lakes Area) is quite the dancer!

btw: that's Jeff Julian there next to him.

There's even video. I especially like the name on the jersey so there's no talking his way out of this one...


Dancing DE
Monday, June 13, 2005 4:38:28 PM (GMT Standard Time, UTC+00:00)  #  Comments [0] 

DevCon 2005 Detroit

DevCon 2005 is on Thursday, June 16th! It's going to be a fun event. We've got a lot of great speakers and content. The speakers include Tim Landgrave, Steve Smith, Bill Wagner and Martin Shoemaker.

We, SRT Solutions, are the only outside Microsoft group to have 2 speakers there.

Four reasons that you should come:

1: Great speakers and great content!
2: Small crowds which mean more face time with the speakers
4: The give aways are worth more than the $99.00 that they are charging
3: Small crowds which give you a better chance to win one of the great door prizes

DevCon give aways



Monday, June 13, 2005 12:18:56 PM (GMT Standard Time, UTC+00:00)  #  Comments [0] 

# Friday, April 08, 2005
Josh Holmes, Microsoft MVP!

I’m pleased to announce that I’ve recently received the Microsoft MVP Award. This is not something that you can apply for. It came from the recommendations my peers and the people in the Microsoft Offices in Southfield for my contributions to the community. I’m honored to be recognized in this fashion and placed in the company of Tom Barnaby, Patrick Steele, Eric Maino, Martin Shoemaker, Richard Hale Shaw and all the other MVPs.

Now for those of you who know me – you’ll get a giggle out of the category because I was awarded the MVP in the C# category.

It’s also exciting because my company, SRT Solutions, now has among it’s principals a MVP (Me) and a Regional Director (Bill Wagner).



Friday, April 08, 2005 1:56:56 PM (GMT Standard Time, UTC+00:00)  #  Comments [0] 

# Monday, February 14, 2005
Speaking in Southfield, MI on Feb. 16

I'll be speaking on Unit Testing at the Febuary GANG (Great Lakes Area .NET Users Group) meeting on Feb. 16.

I'm giving the tutorial and Alex Lowe, now of Telligent Systems, is giving the main talk on Visual Studio Team Systems.



Monday, February 14, 2005 8:07:51 PM (GMT Standard Time, UTC+00:00)  #  Comments [0] 

Speaking in Lansing, MI on Feb. 17
I'll be presenting at the Greater Lansing User Group .NET on February, 17 in Lansing, Michigan. I'll be giving a presentation on Compact Framework and mobilizing your data. If you're in the area, stop by!

Monday, February 14, 2005 8:00:06 PM (GMT Standard Time, UTC+00:00)  #  Comments [0] 

# Thursday, February 10, 2005
NUnit Stands the Test - Follow up

Patrick Steele made a good point about my last post on Unit Testing. The code that I wrote just happened to use the Test keyword at the beginning of each of my methods. That’s not required. I just happed to like that convention because it reads well.

I do use the attributes and encourage everyone else to because, as Patrick also points out, TestDriven.NET and other tools don’t use it.

Look for another article on TestDriven.NET early next week.


Articles | Development
Thursday, February 10, 2005 7:33:23 PM (GMT Standard Time, UTC+00:00)  #  Comments [0] 

# Tuesday, February 01, 2005
NUnit Stands the Test

Unit testing is only enjoyable and productive with the right toolset. NUnit is the foundation of this toolset. It is a unit testing framework for any .NET language.

NUnit leverages Reflection and Attributes to dynamically discover and execute your tests. The structure of a NUnit unit test is as follows.

Imports NUnit.Framework

 

<TestFixture()> _

Public Class DemoTests

    <Test()> _

    Public Sub TestGetIntegerFromConfigFile()

        'Some code that tests the desired functionality

    End Sub

End Class

 

You add the TextFixture attribute to notify NUnit that a class is a suite of tests. You add the Test attribute to mark a method as a single test case. You can have as many tests in a given test fixture as you want and as many test fixtures in a project as you want. The class that is the TestFixture has to be public and have a default constructor so that NUnit can use reflection to dynamically instantiate it. The methods decorated with the Test attribute have to be public, not take any arguments and return no values (Sub in VB.NET and void in C#) for the same reason.

The next step is to write the code that tests the desired functionality. It’s best if the tests are fairly straight forward and simple.

    <Test()> _

    Public Sub TestGetIntegerFromConfigFile()

        Dim demo As VBDemo.Demo = New VBDemo.Demo

        Dim result As Integer = _

            demo.GetFromConfigFile("MyValue", 0)

 

        Assert.AreEqual(1, result)

    End Sub

 

Assert.AreEqual is the really crucial bit of code from this test. This is one of several types of assertions. An exception of type NUnit.Framework.AssertionException is thrown if one of the assertions fails.

Assert.AreEqual(value a, value b)

Tests if b is equal to the expected value a

Assert.AreSame(reference a, reference b)

Tests if two references point to the same object in memory

Assert.IsFalse(Boolean)

Tests if the Boolean is False

Assert.IsTrue(Boolean)

Tests if the Boolean is True

Assert.IsNull(reference)

Tests if reference is Null as expected

Assert.IsNotNull(reference)

Tests if reference is something as expected

More complex tests can be accomplished with normal if statements and the Assert.Fail method.

If (Not SomeReallyComplexStatement) Then

   Assert.Fail()

End If

 

The code that this test exercises takes the name of a configuration setting and a default value. It will return the value from the configuration file or the default value. The test above assumes that the configuration file has a value as follows.

<configuration>

    <appSettings>

            <add key="MyValue" value="1" />

    </appSettings>

</configuration>

 

A small thing that I’ve discovered is that it’s helpful in cases where there is a config file that the tests are in a console application because VS.NET will manage the app.config automatically for you. In addition, if your tests are in a console application, they could be self sustaining and run whether someone has a NUnit test runner, like NUnit GUI, installed or not. You would have to call the tests from the Main of your console application. You know that the test failed when if there is a NUnit.Framework.AssertionException thrown. I have found that this is helpful in a “Clean” environment where developer tools are not allowed.

If the code is as follows.

Public Class Demo

    Public Function GetFromConfigFile( _

            ByVal settingName As String, _

            ByVal defaultValue As Integer) As Integer

 

        Return defaultValue

    End Function

End Class

 

And you run the test; the result will be as follows.

This is expected. Now you need to fix the code so that it will not result in a red bar.

Now modify the function as follows.

    Public Function GetFromConfigFile( _

            ByVal settingName As String, _

            ByVal defaultValue As Integer) As Integer

 

        Try

            Dim reader As System.Configuration.AppSettingsReader = _

                New System.Configuration.AppSettingsReader

 

            Dim resultAsObject As Object = _

                reader.GetValue(settingName, GetType(Integer))

 

            Dim result As Integer = _

                Int32.Parse(resultAsObject.ToString)

 

            Return result

        Catch ex As System.InvalidOperationException

            'Either the value didn't exist or it was not an Int32

            'Fall through to the default value below

        End Try

 

        Return defaultValue

    End Function

 

Once it is, you are rewarded with a green bar as follows.

Since the normal path is working, you need to test the alternative paths as follows.

There are a number of alternative paths that we can investigate. You can pass in garbage, Nothing (or null in C#), the name of an item that’s not an integer and so on. You could decorate the method with an additional attribute, ExpectedException, if we expected this code to throw an exception rather than handle all of its exceptions. For this example, you simply need the non existent config value and the non integer config value cases.

    <Test()> _

    Public Sub TestGetIntegerFromConfigFileNonExistant()

        Dim demo As VBDemo.Demo = New VBDemo.Demo

        Dim result As Integer = _

            demo.GetFromConfigFile("MyNonExistantValue", 0)

 

        Assert.AreEqual(0, result)

    End Sub

 

    <Test()> _

    Public Sub TestGetIntegerFromConfigFileNotAnInt()

        Dim demo As VBDemo.Demo = New VBDemo.Demo

        Dim result As Integer = _

            demo.GetFromConfigFile("MyNotAnIntValue", 0)

 

        Assert.AreEqual(0, result)

    End Sub 

Now you have a well tested function and tests that can be run over and over again.

We have covered the basics of setting up a unit test with NUnit. There are more features that we will cover in a future post. These include the ability to specify setup and teardown methods, categories of tests and suites of tests.

The code for this post can be downloaded below. It does require NUnit.


Articles | Development
Tuesday, February 01, 2005 2:35:12 PM (GMT Standard Time, UTC+00:00)  #  Comments [0] 

# Monday, January 17, 2005
Unit Testing Rocks!

I was skeptical about the benefits of Unit Testing, like many developers I work with. I work with a lot of development teams as a teacher and trainer. I’d seen some teams benefit, but others got nothing but headaches. My latest project has me convinced that rigorous automated Unit Testing is a software development best practice. It saves time, and enhances your ability to create great software. Let me share my experiences on a large ongoing project. It convinced me, and I think it will convince you too.

We introduced unit testing on my current large project, a change from my previous project. Comparing the progress of the two projects has sold me on its benefits. We are several months in and well past the point that I can keep all but the high level architecture in my head at one point in time. The typical scenario on past projects was that I would write some amount of code, one to fifteen lines of code and run the project. I have often included a button on forms that would fill out all of the fields with the minimum required data to speed up the manual testing process. Right here was one issue – I was putting testing code into the production application. The testing process consisted of poking at the application and trying to break things. I would store up two or three issues before trying to run because this process was so painful. Of course, this took ages because I would find something wrong and would have to quit testing, fix the code and rerun. I had no idea how broad changes would be if I fixed a given component. The further down in the architecture, like a database helper class, the scarier this became. Even to test the particular UI bit that I knew that it affected, I would have to log into the app, navigate to the page with the error and then fill out the form and so on. Since I couldn’t possibly know everywhere that was affected this could take a lot of time and it still wouldn’t be right.

Somewhere in here, I would have flash backs to my mainframe days where you’d write code, hand walk it, submit the 10 new lines of code to the compiler and wait. You’d have the results of your compile printed out 2-4 hours later, depending on whether or not the big iron was under load. The next step was to correct the spelling because none of the tools had IntelliSense and start the whole process over again. Throw in a lunch and that was your whole day. You had accomplished the task of compiling 10 new lines of code. The next day, you’d get to test it and then fix it again.
These practices impede forward progress on a project so that I can either laugh or cry.  I stay sane by realizing first that I’m not, by any stretch of the imagination, telling war stories that you haven’t personally felt as well and second, there is a better way now. 

My current project is much different because of testing, testing and more testing. I know exactly what I have and haven’t broken a mere matter of seconds after making the change. Let’s start by talking about the database helper class scenario. I make a change to one of the methods in the database helper class. Now, rather than running and guessing as to what’s changed, fixed or broken, I’ve got automated tests that test that particular method in several different ways directly. I pass in several types of good data and bad data. If it stopped here, that would be good, but it still might have broken something else that I didn’t realize. In addition, I’ve got automated tests for the data classes that use the utility classes. And I’ve got automated tests for the middleware that uses those data classes. And I’ve got automated tests for the ASP.NET UI. And the best part is that all of the backend and middleware tests run in about thirty seconds. The ASP.NET code actually makes the HTTP calls and renders the HTML, parses it and so on so they take a touch longer. Even running all of the tests takes just a couple of minutes.

At that point, I can feel free to move on and write more code without that same knot in my stomach that I’ve broken something that I didn’t know about. I’m not spending time repeating myself and typing in the same meaningless test input into the UI over and over. I am using the computer to do that for me. It makes for more repeatable, consistent tests that actually get executed.
Now, that being said, I don’t believe that the tests that I’m writing can replace the testing that a business analyst, the user or a quality assurance team does. When the tests that I run pass, that means that the code does what I meant for it to do. There are a number of limitations with this. First, it could be that I forgot a possible scenario. Second, the code that does what I meant for it to do might not do what the user or business analyst meant for it to do. If we have communicated well, it will be close but it’s possible that there a misunderstanding which will have lead me down the wrong path.

I still haven’t bought into all of the TDD philosophy. I still don’t write my tests before I write the code. I just haven’t been able to get my head around that concept yet. I have trouble thinking about all of the ways that the code is going to be used and writing tests and then writing the code. I’m thinking that I will make that transition at some point for some tests.
I’ve been thinking that I should take my use cases and start from there writing tests. In future posts, I’ll talk about my thought process here.

One of the keys to a good unit testing experience is having the proper tools. I’ve put together what I think is a good toolset, at least for ASP.NET, that is able to test the vast majority of what I need to test. I'll talk about this toolset and how you can get started on unit testing yourself in future posts.



Monday, January 17, 2005 4:57:46 PM (GMT Standard Time, UTC+00:00)  #  Comments [0] 

# Monday, December 06, 2004
.NET To Go Mobility Roadshow in Grand Rapids - Followup

I want to thank everyone for coming out to the .NET To Go Mobility Roadshow in Grand Rapids. I had a great time and hope to come back to Grand Rapids more often.

We had about 40-45 participants and all seemed to enjoy themselves and were really engaging. If I had a typical Grand Rapids group – I’m definitely going to have to speak there more often. I was a little disappointed at the student attendance as we only had about half a dozen or so and getting students to attend was one of the reasons that we held it at the GVSUAuditorium (Nice facility).

Many thanks go to GVSU – for hosting the event, Eric Maino for organizing and running the event and West Michigan .NET Users Group and the