Pete On Software

RSS Feed

Archive for August, 2008

Lambdas – An Introduction

Lambda Lambda LambdaI will admit that I was pretty confused about Lambdas at first. There was a lot of hype about it and the syntax threw me at first. I wasn’t sure how to read (in English) what the code was trying to do. Some time ago, I decided to really bear down and figure out what this was about and I’ve decided to share what helped me so that maybe it could help someone else.

Lambdas were added with C# 3.0 (which shipped with the 3.5 Framework, which runs on the 2.0 Runtime… ah Marketing!). However, in reality, they are basically some syntactic sugar around anonymous delegates which have been around since the 2.0 Framework came out. Let’s look at this very simple code.

Okay, the Find() and FindAll() methods on the List<T> take a Predicate as an argument. What a predicate is is a special kind of delegate (a way to pass around a function or method like a variable) that evaluates a specific item and determines if it is true or false for some condition. In this case, I return whether or not the object is an integer. I have named my predicate IsInt32 and I pass it by name into the FindAll method.

I could also use an anonymous delegate and just declare the bit of code inside IsInt32 inline to that FindAll method. That looks like this.

In this case, I declare to the compiler that I am going to declare an inline method to use and that it is to be treated as a delegate (and as such can be passed around). If you compile and run both programs, you will see that they produce the same output. But none of this is a lambda. Lets take a look at the last example with lambda syntax.

Okay, we only changed our syntax slightly. We ditched the delegate keyword and we put in this funny => symbol. What that has done is has identified an inline method a different way. In the snippet below we are defining that our method takes a parameter of type object named o and then the => means “this method then does” and then I go on to put code that would exist in that method.

However, we can ignore the type definition, because the compiler can infer the type for us. So that code can then become

That doesn’t read any differently, but this syntax (the common syntax, btw) is what I’ve found confuses the most people. In fact, to prove that I’m not lying to you, I’ve built my project with that line in it (the o=>) and then looked at the code in Reflector. This is what is returned for the relevant section.

As you can see, the compiler took that syntax and merely created an anonymous delegate just like in our anonymous delegate example. You see the delegate keyword is in there, as well as the explicit “object o” declaration.

I can also take a second to “nerd out” about Reflector and point out another bit of compiler trickery. You see that I had been using the “object initializer” syntax when I declared the initial List<object> where I filled the list just by including the items after the declaration inside of the curly braces. If you see the Reflector code, the compiler still has to generate the code that does list.Add(), even if I am spared the keystrokes.

Hopefully, this has been a helpful introductory primer on Lambdas for anyone who may have been having some confusion. Another time I will take a look as to how lambda expressions can be used in LINQ.

WCF Service Error

I was modifying a service last night and I got this error when I hit one of the two endpoints of the service.
The server was unable to process the request due to an internal error...
For search engines (and anyone having a hard time reading the image), it says:

The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework 3.0 SDK documentation and inspect the server trace logs

The other endpoint on my service was unaffected. Usually when I do something stupid, I get the “Yellow Screen of Death” the first time I try to reach my service due to an improper web.config or some other easily correctable thing. This was the first time that I had seen this.

I did some Googling and found out specifically how to get the “real” error message. I had to change my serviceDebug tag in my service’s web.config (located in system.ServiceModel/behaviors)

This gave me a much more helpful message telling me that one of the elements in one of my request objects had already been defined (name and type were the defining factors) in another existing request.

There were two fixes for this. Once was a “hack” in my opinion and the other was the “correct” solution. The hack was to turn off metadata exchange on that endpoint (my particular error was related to generating the WSDL). To do that, I would have set the

to

and remove this line from beside my endpoint definition.

That would prevent developers from inside the company from generating proxy classes automatically with svcutil.exe. I didn’t want that at all.

What I did instead was to rename the element to something that made more sense anyway. This time when I built, the endpoint came up with no problem and the link to the WSDL returned the proper XML that developers would need to “reproxy”. Problem solved and lesson of the includeExceptionDetailInFaults learned!

TDD with NUnit

If you haven’t read my first NUnit post and aren’t familiar with NUnit or TDD, you might want to check it out here.

Last time we just looked at the basic ways that you make tests and use the test runner to verify their results. In this post, I’d like to examine how you might go about doing true “Red. Green. Refactor.” Test Driven Development (TDD).

First, I’d like to make a new C# Class Library Application named MathHelper. Rename Class1.cs to MathClass. Additionally, immediately add another project to the solution. Right click on the solution, Add-> New Project. Choose a Class Library Project and call it MathHelperTest. Rename Class1.cs to Tests.cs. Add a reference to the nunit.framework dll and the output from our MathHelper project. Your Solution Explorer should now look like this.
The initial Solution Explorer.

Now, we do need to have something so that the test class will compile and we do have a general idea of what we need from requirements gathering, so put the following code in the MathClass.cs file inside the MathHelper project.

What you can see is that I’ve stubbed in the methods that I expect my class to contain. What I’ve also done is make sure they all throw NotImplementedExceptions when they are called, since I’m not writing any functional code until after I write my tests.

So, lets write some tests already! In Tests.cs inside of our MathHelperTest project, enter the following code.

Okay, for the sake of simplicity, lets fire up our NUnit GUI and load the MathHelperTest.dll and run our test suite. (If you are unsure how to do this, please refer to my initial NUnit post). It should come as no surprise that all four of our tests failed with Not Implemented failures. Now, lets go back and add some code to make the tests pass.

Change the code in MathClass.cs to this:

Run the tests again and they should all 4 pass. Woohoo, we’re done, right? Well, not exactly. First of all, our test coverage met the minimum requirements, but didn’t really test the code very well. Secondly, our Math implementation isn’t very great. Let’s solve the first problem first and add some more tests.

When we rerun our tests in the NUnit Test Runner, we now see that two of them fail (TestDecimalExponent and TestNegativeExponent). Lets see if we can fix our code. MathClass.cs should now look like this.

Okay, all tests pass. Now, lets see if we can do the Factorial method a little better and use a little recursion. We can safely experiment, because we know that our unit test will ensure that it still returns the correct value.

Run the tests and we’re still green, so we’re good. You would continue to go on in this manner. Add additional tests first to test functionality, then code the functionality, then refactor your code to make it efficient, extensible, and maintainable and run your tests again until all is green.

I understand that we could take this sample code further, write more tests, and create better code, but that is always the trade-off. You have to take into account where your code will be used, how mission critical your app is, and decide what level of risk your code can have due to anything less than 100% brilliant testing with 100% code coverage.

NUnit

NUnit. Chances are that you know what NUnit and Test Driven Development are, but if you don’t I’ll give you a quick primer. Test Driven Development means that you drive your development from tests. I know I just reversed the order of the words, but lets take a look at what that means 😉 Test Driven Development has a little motto that goes, “Red. Green. Refactor”.
Red. Green. Refactor.

The red refers to writing the tests for what you want your code to do before you write the code to do it. When a test fails in NUnit (and other Testing Frameworks), they show up as red. Next, you write the actual functional code to make the test pass (green), and then you refactor the code so it is as clean, extendable, testable, and maintainable as possible. Then you run the tests again to make sure that none fail. If they do, you fix your code so that the tests can pass again. You repeat this process as much as is prudent for the project that you are on.

The extra added benefit is that you can feel safe in making changes to your code later. If you have written sufficient test coverage, you can run your tests and if they all pass, then your changes will cause no problems when you deploy.

Now, on to NUnit. NUnit is the first unit testing framework that I ever heard of or used, so I have a soft spot for it. You can get started by downloading NUnit from their download page here. The easiest way to get going quickly is to pick the download named NUnit-2.4.8-net-2.0.msi and then just run the install wizard.

Once you have everything installed, let’s get started. For a sample, let’s just make a new C# class library project called NUnitExample. Add a reference to nunit.framework.dll that can be found at (if you accepted the defaults on install) at C:\Program Files\NUnit 2.4.8\bin\nunit.framework.dll.

Now, enter the following code into the default Class1.cs file and build the project:

Now, fire up the NUnit Test Runner GUI. It is located at C:\Program Files\NUnit 2.4.8\bin\nunit.exe. When it opens, click File –> Open Project and then navigate to the .dll that was created from the project that you built and click “Open”.

The NUnit GUI should now look like this:
NUnit Ready to Run Tests

Make sure you have the top level highlighted and click Run. It will look like this:
NUnit After Initial Tests

What you see is that the entire test fixture of NUnitExample has failed (the red circle with the X). Parent levels are always shown as having the same success level as the lowest success level below it. You see that Adding, Comparison, and DivideByZeroException passed. No surprise here. Additionally, the three tests named ignored have been ignored because their signatures were incorrect. If you click the “Tests Not Run” tab at the bottom of the runner, you can see why.
Reasons for ignored tests

If you click the “Errors and Failures” tab, you will see why the Dividing Test failed.

Oh, yeah. Integers only hold whole numbers. Lets go back and change the code. (Normally, you’d change your code, but here the “active” code is embedded in the tests because of this simple sample.) Change the Dividing test to the following:

When you switch back to the NUnit Test Runner, it will have automatically refreshed because the test project has changed. Run it again and the Dividing test will pass and the overall status will be yellow because the lowest level of success in the child tests was also yellow.

If you instead would like to use the command line for NUnit (perhaps for continuous integration or just as part of your build task on your program) you can do that as well. Open a command window and enter the following command: (If you changed anything on NUnit install, change “c:\Program Files\NUnit 2.4.8\bin” to match your install path. The argument passed in is the path to the .dll of the project that you created.)

When you run it, you get the following results:

In a later post, I will look at doing Test First development with a true “Red. Green. Refactor.” feel.