TDD Weather Series Part II - WeatherResults Converter

Continuing where I left off with the initial installment on building a Weather application, I am going to start building a converter that will convert the results from the CDYNE's weather services GetCityWeatherByZip webmethod into a CurrentConditions object.

The GetCityWeatherByZip method returns the results of a zipcode query in the following structure:

In this application, the requirements for a valid CurrentConditions result will be the following required fields:

• Success
• City
• State
• Temperature
• Remarks

I setup a new solution and add a test project.  In that project, I add a new class called CurrentConditionsTests and add my TestFixture attribute.

My first test will be to create my CurrentConditions class and setup the constructor to accept a string.  Remember, a test that cannot compile constitutes as a failing test.  Using the [Alt-Enter] keyboard shortcuts in Resharper, I quickly create my CurrentConditions class and get the constructor all setup.

With my code completed, I re-compile and run my test.
The next test would be to make sure my new class can get to my first required element; Success;  In a new test, I make sure I only give the CurrentConditions constructor something, say "foo" and verify the property.  When building this test, notice that I have not yet created the Success property. I again use Reshaper [Alt-Enter]  to quickly create this property.

To make my test pass, I do the easiest thing:

Doing the easiest thing forces me to create another test to drive out getting the success element data, so I create another test and supply different data;  "<WeatherResult><Success>false</Success></WeatherResult>".
To get my tests passing I have to a bit more functionality to the code.
When I run all my tests, my first tests fails because it's trying to load an empty string into an XmlDocument. The second test also fails because it's trying to load "foo" into an XmlDocument. To get these tests passing, I'll delete the first since its only purpose was to build some really basic infrastructure. Secondly, I'll update the second test with a valid Xml snippet to return true.

The next set of tests will focus on the validity of the field as well as the fields existence.  In my example, if the WeatherResult does not have the Success node, my code needs to throw an Exception.  My new test looks like:


When I run this test, it fails because my code did not throw an ApplicationException.
To make it pass, I need guard condition for my property:


The last validation step is to verify the Success property can convert the result to a bool, if not, set it to false. Here is the new test:

To pass:

Yuck, now I get to say one of my favorite phrases. With TDD it's OK to write crap, because you get to refactor. That's a lot of nasty stuff in the property getter. I like my properties nice and clear, it should return a private variable.
With a little refactoring, my code now looks a little better:


With that refactoring, I need to have the diligence to make sure my tests are still valid. My one test, ShouldThrowIfSuccessIsMissing, no longer needs to access the Success property to throw since I moved that code to the constructor.


I think this is a good place to stop for this post, it's getting a little long. The next post, I'll add tests for the second required field and get into some really fun refactoring. Comments are welcome!

TDD Series - Weather Application - High level design

This series will be a step by step process to build an application demonstrating the TDD cycle, evolutionary design, least responsible moment, and the use of stubs and mocks.

In this first installment, I will describe the high level design of an application I will be writing to consume and display results from a weather web service and the initial stub to fake out the web service return results.

The web service I will be using is by CDYNE.

The application will have the following basic components:

• Presenter
• Controller
• ServiceProvider

Pictorially, here's how the app will be put together:

Program Design:

This design will allow me to test in isolation. Isolation allows me to test how the application will behave in all aspects without actually running the application.

Controller:

One of the important details you do not see in the above picture is the fact that the constructor for the Controller does not show the dependency injection of a IPresenter and a IWeatherProvider. The controller will use a WeatherProvider to get the Xml results from the web methods and in turn convert the Xml in to an object so it can be displayed on the UI via IPresenter.

Here's the toolset I will be using to build this application

• Visual Studio 2008
• NUnit
• Resharper

In Visual Studio, I created a blank solution and added two class libraries. I also added references to NUnit.Framework, Rhino.Mocks and a project reference to WeatherDemo.

OK, let's get started!

I want to have the ability to get results from my web service, but I don't want to call it for every single unit test. To get around this, I am going to create a stub. The stub gives me the ability to simulate the method calls and only concentrate on converting the results.

In my test assembly, I add a class called WeatherControllerTests and add my TestFixture attribute

The first thing I need to do here is to create the actual stub that will return my supplied Xml results. To create the sub, I'll create a simple test.

Here enters the TDD Cycle:

1. Write a test
2. Watch it fail (Compile errors count as failures)
3. Write some code
4. Watch test pass
5. Refactor
6. Run Test(s)
7. Repeat

If I try to compile, I will get an error that ServiceProviderStub does not exist. Using Resharper, a quick Alt-Enter takes care of that. Compile and re-run the tests.

All the code I have typed so far is:

The next step is to setup the stub so that it returns Xml similar to what the actual web method returns. I want to setup the stub so that it returns what ever string I give it as an XmlDocument. This will evolve as needed and dictated by my tests. My next test would be like so:

With the help of Resharper (Alt-Enter), I create my method GetCurrentConditions that takes an int and returns and XmlDocument. Also, I need to create a way to inject my Xml test samples, a SetWeather method fits the bill. Thanks to ReSharper, I already have the GetCurrentConditions method in the interface so when I implement my "real" class this will be the pass through method. Once I can compile, I run the test and watch it fail.

To make it pass, implement this code:

With my stub all set, my next step is to create another class that will convert the Xml results into some sort of object so is can be passed on to a Presenter. I'll cover that in my next post.

Oh, those pesky semi-colons!

I have a great fascination on the origin of things, whether it is the current set of books I am reading about early American history₁, or the various nostalgic videos on the beginnings of Microsoft, or even the posts by Andy Hertzfield on the early beginnings of the Mac. C is a language that has that same nostalgic appeal to me as well. It's the pre-pre cursor to C#, the language I actually get paid to write in. In life's continual twists, I am now on a team that has some applications that interface with C and C api's. Most people I mention this to reply, "ugh.. you have to learn C?!?!?" But to me, it's something to learn and since C is the predecessor to C#, it scratches my itch for learning about the origin of things.

On a recent trip to my local public library there is a shelf for free books, and to my amazement, there was a copy of Problem Solving & Program Design in C. Sarcasm aside, I couldn't understand why it was still there for my taking. In the chapter on arrays, there is a simple program on writing a stack, I added a print function to this program to list all the elements.

This code compiles, but when I ran it, I only saw the last element in the array. Hmmm...strange. I fooled around a little adding some extra printlines, check some other code snippets and I can't find what is going on!

Eventually, after a day or so, what was wrong was I had a semi-colon at the end of my for loop declaration. The C compiler accepted this code as valid code and when my program ran, the for loop looped over itself, never proceeding into my brackets until i <= *size was actually true, then only printed the 3rd element in my array!

To me, there are several thoughts I took away from this little problem.

• What a great lesson to enforce really reading your code before you execute.
• An increased appreciation for the C# compiler to not let me even make that mistake in C#. (The compiler gives you a warning.)

I would love to see what comments, if any, others have on the merits of learning C, really learning C, when your primary programming language is C#. Personally, I see merits in knowing/learning this language if not for the only habit to slow down and really read my code.

---

₁If your looking to get a nice start on early American History, I suggest the following:

• John Adams by David McCullough
• 1776 by David McCullough
• Benjamn Franklin by Walter Isaacson
• Founding Brothers by Joseph Ellis

These authors have written several additional books, but these are great primers on the subject.

Haskell - Lists

Haskell - Lists

Lists in Haskell are defined by square brackets, [].  In ghci, declaring a list is as simple as:

Prelude> [1,2,3]
[1,2,3]

Lists can be of any length, indeed you can type in the following (although I wouldn't recommend it!)

Prelude> [1,2, .. ]
[1,2,3,4,5,6,7,8,9,10,11,12....]

To create an empty list, type the following:

Prelude> []
[]

Lists must be all the same type, if we try to declare a list with the following, we will get an error

Prelude> [1,3,5,7,"nine"]

<interactive>:1:7:
No instance for (Num [Char])
arising from the literal `7' at <interactive>:1:7
Possible fix: add an instance declaration for (Num [Char])
In the expression: 7
In the expression: [1, 3, 5, 7, ....]
In the definition of `it': it = [1, 3, 5, ....]

What the interactive session is telling us here is there is a type incompatibility between Num and [Char] and suggests some possible fixes.

Operating on Lists

To concatonate two lists you use ++

Prelude> [1,2,3] ++ [4,5,6]
[1,2,3,4,5,6]

To add an element to a list use the cons operator :

Prelude> "Nate" : ["Bill","Ted","Stephen"]
["Nate","Bill","Ted","Stephen"]

List Comprehensions

List comprehensions are really a thing of beauty, although, the Haskell Wiki labels them as syntatic sugar.  I think they add an element of beauty and simplicity.  Comprehensions follow the basic syntax₁:

[ e | q₁ .., q_n], n >=1

where the q₁ qualifiers are:

1. generators:  p <- e, where p is a pattern of type t and e is an expression of type t
2. guards: an expression that evaluates to a bool
3. local bindings: provide new definitions for use or subsquent generators or guards

Here's an example of how to generate a list of all even numbers between 1 and 50 using comprehensions:

Prelude> [ x | x <- [1 .. 50],even x]
[2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42,44,46,48,50]

Granted, you can accomplish the same thing using arithimetic sequences:

[2,4 .. 50]

But take a look at how to solve Project Euler question #1 with list comprehensions:

Prelude> foldr (+) 0 [x | x <- [1 .. 999],x `mod` 3 == 0 || x `mod` 5 == 0]

Breaking down this line into parts,

Prelude> foldr (+) 0 [x | x <- [1 .. 999],x `mod` 3 == 0 || x `mod` 5 == 0]

x <- [1 .. 999] is a generator, it's using an arithimetic sequence to get all the numbers between 1 and 999. 

Prelude> foldr (+) 0 [x | x <- [1 .. 999],x `mod` 3 == 0 || x `mod` 5 == 0]

x `mod` 3 == 0 || x `mod` 5 == 0 is a guard or predicate.  Only when this expressions is true is it "passed" to the new list.

Prelude> foldr (+) 0 [x | x <- [1 .. 999],x `mod` 3 == 0 || x `mod` 5 == 0]

x is the new list of all the numbers between 1 and 999 that satisfy the predicate.  Then, x becomes part of the last expression, the foldr function.

foldr, or reduce, applys the the operator + in this case to the seed value 0 and each element in the list.

---

Learning Haskell

Why am I learning Haskell? 

There are several different answers, but there are a few that stick out more than others.  While I was learning F# and making my way through ProjectEuler problems, I was getting frustrated with running into type issues.  Here I was looking at some beautiful, clean and consice code, and then watching it get all cluttered up with F#'s casting syntax.₁ 

Another reason is when I finally solved a Euler problem and quite proudly submitted my solution, I would browse the other F# solutions and became dissapointed with what some others where submitting.  I was looking at F# syntax, but it was all procedural style.

F# is a great language and I really enjoy writing with it, and will continue.  However, I wanted to learn functional programming on a language that doesn't allow me to break the rules.

Getting Started with Haskell

I am using the GHC implementation, which can be downloaded here.  With the download you get three components:

• ghci - an interactive interpreter
• ghc - compiler
• runghc - runs Haskell programs as scripts

My examples will be in ghci, but I'll note when I switch.  My development environment is a Mac, so the command window is the bash shell.

After installing Haskell, launch Terminal and type in ghci:

$ghci
GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
Prelude>

Once the ghci is loaded, we see several libraries being loaded, ghc-prim, integer and base. Details on these packages can be found here.

The Prelude> prompt means the prelude library is loaded, sort of shorthand for the prelude 98 standard.  Like other Unix shells, what you see for the prompt is configurable, but I"ll leave the default. 

One of the more import things to remember when you are starting is, :? This will list commands available from the prompt.  To execute an operating system or shell command, type in :! So to see what directory you are, type in

Prelude> :!pwd
/Users/nathanhoellein/HaskellProjects

To change directories, you need the :cd command.

Prelude> :cd ./ch03//
Prelude> :!pwd
/Users/nathanhoellein/HaskellProjects/ch03

Another command that's interesting is

:browse

It lists all names loaded by module.

Interactive Haskell

The ghc interpreter functions just like the F# interactive console, you can type in code snippets and perform arithmetic, except you don't have to end each line with ;;. 

You can perform calculations using infix or prefix syntax:

infix: 

Prelude> 2 + 3
5

prefix

Prelude> (+) 2 3
5

Integers can be large, see what happens when you want to know what 2 ^ 100 is:

Prelude> 2 ^ 100
1267650600228229401496703205376

Whereas in F#, you have to use doubles and you get a little different output:

> 2.0 ** 100.0;;
val it : float = 1.2676506e+30

What I find pleasing is you can see F#'s roots, the keyword "it".

The "it" variable sort of holds on to the last expression that was evaluated. 

Prelude> 2 ^ 100
1267650600228229401496703205376
Prelude> it
1267650600228229401496703205376

We see the same in F#:

> 2.0 ** 100.0;;
val it : float = 1.2676506e+30
> it;;
val it : float = 1.2676506e+30

Other arithmetic stuff within Haskell:

Prelude> 2 - (-8)
10
Prelude> 2 + (-8)
-6

And booleans:

Prelude> True || False
True
Prelude> True && False
False


Like basic algebra, order of operations matter:

Prelude> (1 + 3) ^ 4
256
Prelude> 1 + (3 ^ 4)
82


That's a nice start for now, next post I'll cover lists.

---

₁ - Yeah, I know it's really the .Net runtime

Test faster with Tools

With the release of TestDriven.Net version 2.16, you can now run your F# unit tests within Visual Studio. Prior to this version, I would execute my unit tests via NUnit-Gui, or xUnit's command line utility. Both tools are wonderful for handling unit tests, but like most, if not all programmers, I am lazy. I was getting very tired of switching windows. I even wrote my own small testing harness, here but I still had to fuss around with switching windows.

I do realize that all it took was a simple keystroke combination of alt-tab, but waiting for my machine to re-paint the windows and the tools to re-load the new assembly became tiresome. To add to my laziness, in order to run my tests when in C#-ville, I assigned keystokes TestDriven.Net run tests method, I didn't even have to use the mouse! Resharper is another tool I use when I am programming in C#-ville, although Resharper has not yet made it way in to the F# world, there are still parts of the tool you can use. Consider the blank F# page, when you start a new project. All you get is:

#light

Not much here to get you started. So I created a ReSharper Live Template called "fixturef".

When I press the tab key, I get the following:

Viola! I don't have to type any of the setup structure to get my base Test Fixture!

Wait, there's more!

I also created another ReSharper Live Template, called "ftest":

When I press tab:

Viola! All I have to do at this point is type the rest of my test methods name.

By now, I know you're now asking yourself, "it can't possibly get any lazier", but oh yes, it can!

When I actually have to type some code to get a unit test ready to run, I got tired of having to reach the 10 inches for my mouse and perform a series of point-and-click operations. TestDriven.Net provides commands that you can assign keyboard shortcuts to. In Visual Studio, go to the options screen and select Keyboard. In the command name text box, start typing TestDriven. There are a series of commands to invoke TestDriven.Net. I assigned the ctl-alt-shift-T keystroke to the TestDriven.Net.RunTests command.

So now when I have a test to run, I can press ctl-alt-shift-t and invoke TestDriven to run my tests. No more window switching, or mouse-clicking!

You get a nice message in the status bar of Visual Studio, letting you know the status of your test run.

Oops, one test failed, all I have to do is use the ctl-tab keys to switch between documents in Visual Studio and I see the results of my tests in the Output window.

Enjoy my laziness!

Wow – What a trip. F#, C#, TDD, COBOL and enlightenment

Life truly has a fantastic humbling ability. A few months ago I was in the midst of a deep dive, swimming in the goodness of F#. I had all sorts of wonderful ideas on future blog posts. I was treading in a veritable pool of functions, records, pattern matching, currying; all while not getting bogged down in semi-colons and missing curly brackets! I was on top of the world.

Then life reminds you what is truly important, my wife and I were blessed with our 3rd child at the end of May. What a wonderful addition to our family. So after one month of anxiety waiting for the baby to arrive and then another two months of interrupted sleep, burping, changing diapers and worrying about poop, (those of you with kids understand!) my thoughts never strayed too far the pool. So here I go, with a great big cannonball, I splash back into the blog waters. It was during those few months out of the pool, when my only concentration on coding was in C#-ville from 9 to 5, several statements of a profound nature crept into my head. I have been long since spoiled on the benefits of Test Driven Development (TDD); write a test, write some code, make the test pass, refactor, run tests - beautiful simplicity.

As simple as that is, one of my co-workers would always write extra code; code that was not needed to make the tests pass. He could not bring himself to just write the simple code that made the test pass. I would always ask the question, why did you write that? The test would still pass if that block was not there.

His reply was always, "We'll need it soon." Rather than argue, because he would be right, and delete the code he had written, we would go on our way and complete the task at hand. (By the way, when teaching TDD to someone new, deleting code that has no coverage is a great way to enforce the rule that you shouldn't write any code that is not a result of a test!)

So one day, our group was having a small discussion while taking a break from coding and talking about past jobs and different languages we knew. This guy mentioned he programmed COBOL for several years prior to migrating to java and C#. While I snickered and mentioned my own experience with COBOL; a mere two semesters in college and a professor that couldn't code, he laughed and said, "you had to be careful about your code, if you had a bug, you could crash the entire system for everyone". So after my casual chuckling, I repeated his statement and added something to the effect of, "wow, I would have surly pissed of a lot of other developers, my code is always buggy, I rely on tests to find them, not the final run." As soon as I said that, the little light switch in my head clicked and I then realized why our coding styles were so different, why he just couldn't write the simple code and trust the tests.

Being faced with the situation of crashing an entire mainframe, COBOL developers, at least this one, had to make sure the code was sound before submitting your code to the queue. Comparatively speaking, if I crash my system, 1 person is down for a little while, but if you take down an entire mainframe region, there's a little more impact. (I am not picking on COBOL developers here, it's just part of the story.)

Compare that to TDD, where my mindset is, "hey, if I refactor this chunk of code into a method, these two other block are the same, and could be made a delegate. Let's try that!" Or, things like "I don't like that switch statement, lets make it a dictionary". Compile, Run Tests…. oops, the entire test fixture fails, oh well, ctl-z.

This tantalizing story leads me up to these few points:

Profound statement #1: TDD is an incredible gift. Having a series of unit tests gives you the confidence and comfort to try really crazy things with your code. It also gives you the ability to enforce some of the higher level design patterns to make your code truly awesome; open closed principle, single responsibility, Liskov substitution principle, to name a few.

Profound statement #2: TDD has made me lazy. I let my tests find my bugs.

Profound statement #3: TDD has made me confident. I realize that this statement might conflict with statement #2, but mixing of these traits just makes me smile. If my QA tester finds a bug, I can write a test to re-produce the issue and can guarantee that bug will not surface again.

Profound statement #4: You need productivity tools like ReSharper and TestDriven .Net. Not to sound like a commercial for ReSharper, but man, that stuff is like crack! When you combine those tool suites, with your IDE, you can do really fun things when pairing like "mouse free Thursday's". Once you learn all the keyboard shortcuts within an IDE, you realize the mouse is a distraction. The speed, fluency and pace you can write, and refactor code triples when you are not fumbling around with that little pointy arrow. You find that your thoughts are focused on your end goal and not scrolling through your code looking for those pesky syntax problems like missing curly bracket or missing semi-colon. And yes, it is a bad habit to rely on the compiler to tell you were that missing semi-colon is!

So now here's my disclaimers.

1. I have respect for COBOL programmers, my intent here was to not poke fun at them.
2. I am not pushing ReSharper or TestDriven.Net, those are the tools we use. There are productivity tools out there. ( If Dustin Campbell reads this, I'll have already heard the groans when I mention ReSharper!)
3. Mouse-Free Thursdays is an awesome experience. While pairing, each developer unplugs their mouse, only for Thursday and only while coding. After a few MFT's, you find you are a much more efficient coder.