I've understood and attempted to follow TDD practices for a while. The initial understanding of it was pretty tough, and very, VERY sporadically put into practice. After all, it's a pretty big shift in thinking when you first encounter it. "Write tests? For code that's not there?? Wow, that's fantastic!!"
So, over time I've gotten much better at the whole TDD thing. Or so I had thought.
Wednesday, mid-presentation, my lack of patience with the system outed me. I had written my tests, passed my tests, changed my code, changed it a little more, and then went to present it. Wow did I get smacked in the head by not running the tests after each change. (Continuous integration for a small demo app didn't really enter my mind. I have a hard time firing up CI at home since there's not much to I, but maybe I should join Mr. Donaldson in doing so.) So, big time lesson learned there.
The flip side to that bit of a stumble was the amount of time TDD saved me on my current project at work. I had written a number of unit tests to cover some business logic, and a few integration tests. A couple of defects came in showing that I needed to change a number of my dates to nullable objects. Not a difficult change, but not totally trivial, either. Made the changes, ran the tests. Oops...more changes, ran the tests. The whole change over was done, tested, and passing within 15 minutes.
A few pitfalls I've fallen into while traveling down the path towards TDD enlightenment:
1. I tend to wrestle a lot with when to layout some of the framework and when to just breakdown and write the tests. The main reason I wrestle with this one is that the good ol' crutch of intellisense sure comes in handy for test writing if you've framed your code out some. (When writing Ruby code in e, this doesn't seem to be as much of an issue for me.)
2. A recent project found our team working with a pile of generated tests. With the ever present deadline looming larger and larger, we decided to go with the generated tests as they appeared to be "good enough." They were good at the start, but as the code base grew, and our tests with it, we started looking at our CI build taking up to an hour. There's a big red flag. Dug into the code, very few unit tests were generated, but a pile of integration tests were. Takes a while for nHibernate to do its thing 4,316 times. (We've since started cleaning that up, build is back to a more reasonable, but still outrageous half-an-hour now...)
3. When to mock? I'm hip to the whole mocking thing, but identifying the right time to do so is still giving me troubles. I'm sure I'll get there with practice, just need some more practice.
4. Is this test trivial, or needed? In a previous post I mentioned viewing code coverage the other way around, seeing what's uncovered rather than covered. I don't see 100% coverage, er I mean, 0% uncovered as attainable in the web projects I usually work on, but where do you draw the line? If you end up falling over on a piece of untested code, I guess it wasn't trivial.
5. I still have large holes in what I test. Just about all of my javascript code is completely untested. I know there are frameworks available to help me with that, but I haven't gotten down and dug into them.
So, short term I'm going to keep the ears pinned back and keep moving forward with the testing first. May as well get a home build server set up, and keep digging on mocking as much as I can. Gonna have to investigate Moq, as well. Also, time to get that javascript tested. With as much AJAX as we're cranking out, this is quickly becoming a priority.
Sunday, March 30, 2008
Tech Night - Getting Started with MVC
First of all, thanks to all those who attended TechNight this past week at QSI HQ. That was by far the largest crowd I'd seen gather for TechNight, much bigger than the 10 people that came in September when I presented on ASP.Net AJAX. With Quick having the much larger training center now, I hope this trend continues.
The Snag
During post-presentation discussions, I finally arrived at why the test failed. Short version: I'm an idiot.
Long version: I went with the whole TDD approach to the presentation to show how MVC was more testable. It is a great way to show some of the advantages of MVC. It is if you continue to run those tests as you refactor your code.
What I did was stop at red, green, refactor. I didn't try for more green following an additional refactoring. I had written and passed my product controller tests, where the big test failure happened in the presentation, before I had added my model code to the product controller. That's a pretty big change, and clearly the tests caught that change...in front of an audience, rather than in the comfort of my own home.
So, my protests of, "These passed at home!" were correct, because I only ran them once. Like I said, idiocy.
In the end we got it working for purposes of the demo, and I owe Mel, Steve, Steve, Kris and many others who shouted advice a big thanks for helping me over the hurdle. However, the demo ended up testing what I didn't need or want to test: That LINQ was doing what it said. I had wanted to add one more test prior to the demo that hit an in memory collection of products, that would have solved my problem with the connection string and been a much better test of the controller code.
Here is a link to the code and slides: Getting Started With MVC
That resisdes in a SVN repository on Google Code (thanks Steve), and will get updated as I update the presentation. Clearly I have a couple of tests to add, some data issues to clear up, and will probalby change the slides some as it progresses. Keep an eye on it in the near future for updates, CODoDN will be here before I know it.
The Snag
During post-presentation discussions, I finally arrived at why the test failed. Short version: I'm an idiot.
Long version: I went with the whole TDD approach to the presentation to show how MVC was more testable. It is a great way to show some of the advantages of MVC. It is if you continue to run those tests as you refactor your code.
What I did was stop at red, green, refactor. I didn't try for more green following an additional refactoring. I had written and passed my product controller tests, where the big test failure happened in the presentation, before I had added my model code to the product controller. That's a pretty big change, and clearly the tests caught that change...in front of an audience, rather than in the comfort of my own home.
So, my protests of, "These passed at home!" were correct, because I only ran them once. Like I said, idiocy.
In the end we got it working for purposes of the demo, and I owe Mel, Steve, Steve, Kris and many others who shouted advice a big thanks for helping me over the hurdle. However, the demo ended up testing what I didn't need or want to test: That LINQ was doing what it said. I had wanted to add one more test prior to the demo that hit an in memory collection of products, that would have solved my problem with the connection string and been a much better test of the controller code.
Here is a link to the code and slides: Getting Started With MVC
That resisdes in a SVN repository on Google Code (thanks Steve), and will get updated as I update the presentation. Clearly I have a couple of tests to add, some data issues to clear up, and will probalby change the slides some as it progresses. Keep an eye on it in the near future for updates, CODoDN will be here before I know it.
Wednesday, March 12, 2008
Is code coverage worth bragging about?
I'm a hockey fan, have been for a while. In being a hockey fan, I've had a number of statistical discussions around the sport. Second only to baseball fans in statsville, hockey fans love their numbers. One major discussion took place around shots on goal. That semi-subjective stat that tells a team how many times the goalie got between them and a goal. I've seen teams put 40 shots on net and lose to a team that got 18 because 3 of the 18 went in and only 1 of the 40. After the game, you lost, but hey...you put 40 shots on that guy! You certainly didn't lose for a lack of trying.
So, over in the software world, I'm now wondering if Code Coverage is our shots on goal stat. You get over beers and start talking with peers and hear...
Bob: "I've got 40% code coverage!"
Terry: "Bah, that's nothing, we hit 55% this afternoon!"
James: "You both suck, we've got 70% coverage and are almost through UAT!"
Here's what's missing in that discussion...Bob is 60% uncovered, Terry is 45% uncovered, and James has 30% of his code waiting to spring something on him in the next few days of UAT. In essence, they've each got a number of shots on goal, but how many are in the net? Are we focused on the wrong side of the equation?
The goal of 100% code coverage is a tough one, unless you're Joe O'Brien. (See: Testing Mandatory, CodeMash 08) In my life in ASP.Net, getting 1% coverage on a code behind file would be worth a round of beers.
But, are we focused on the wrong goal? Clearly, increasing your code coverage is decreasing uncovered code. But, if your goal is 75% coverage and you reach that goal, do you stop? Maybe shifting our focus to code uncoverage will close that gap.
Don't be happy with those 40 shots on goal...
So, over in the software world, I'm now wondering if Code Coverage is our shots on goal stat. You get over beers and start talking with peers and hear...
Bob: "I've got 40% code coverage!"
Terry: "Bah, that's nothing, we hit 55% this afternoon!"
James: "You both suck, we've got 70% coverage and are almost through UAT!"
Here's what's missing in that discussion...Bob is 60% uncovered, Terry is 45% uncovered, and James has 30% of his code waiting to spring something on him in the next few days of UAT. In essence, they've each got a number of shots on goal, but how many are in the net? Are we focused on the wrong side of the equation?
The goal of 100% code coverage is a tough one, unless you're Joe O'Brien. (See: Testing Mandatory, CodeMash 08) In my life in ASP.Net, getting 1% coverage on a code behind file would be worth a round of beers.
But, are we focused on the wrong goal? Clearly, increasing your code coverage is decreasing uncovered code. But, if your goal is 75% coverage and you reach that goal, do you stop? Maybe shifting our focus to code uncoverage will close that gap.
Don't be happy with those 40 shots on goal...
Tuesday, March 11, 2008
Mix08 Recap
My recap of Mix08 has to start with a big thank you to Jeff Blankenburg, and the small company he works for based in Redmond, WA. Jeff got me a ticket to Mix (QSI got me the plane ticket and hotel stay), then once I got there he got Colin Neller, who runs the Memphis user group, and myself tickets to the Blue Man Group. Then when the White Death hit Columbus and our flight home got cancelled, Jeff put us up in his room for the night because he was staying one more evening. (Oh, and he loaned me $40 at the craps table…but he told me the juice is running on that.) If your DE is to drive more interest, JB is doing a good job getting me around the Microsoft community.
Second big thank you is going to go to Steve Harman. Steve and I both work for Quick, and roomed together while at Mix. (That’s the rest of the “us” that Jeff put up courtesy of the Blizzard of ’08.) Steve has a number of contacts in the community, and he introduced me to everybody he knew, and some he didn’t know. (And after our interesting trip home, Steve and I didn't kill each other, and we're still speaking.)
So, with Jeff and Steve leading the way, easily the biggest part of Mix for me was the people I met. There were a number of sessions I didn’t go to as I stayed in the Open Spaces/Sandbox area to just talk with people. So, I may have missed a Silverlight session, but I got to spend about 35 minutes talking to Phil Haack about the ASP.Net MVC framework. The guy writing that framework has to be a pretty solid source of information. Later I watched the Steve Balmer keynote with Rob Conery. Rob shared a lot of what his general development practices are, and what tools he uses. (I didn’t luck out and have beers with ScottGu like Steve did, though.)
I did get to a few sessions, though. The highlight one for me was Scott Hanselman’s talk on the ASP.Net MVC framework. Since I’ll be doing one of those myself on March 26th, figured I better watch Scott to get some materials to borrow…er, I mean get ideas. I also got to see Nikhil Kothari talk about ASP.Net AJAX apps moving forward, which was pretty cool for me since I got a lot of information from Nikhil back when I was picking up on what was then ATLAS. One of the better sessions was a panel discussion on Open Source and where it’s headed. The panel consisted of Mike Schroepfer (Mozilla), Rob Conery (Microsoft), Andi Gutmans (Zend), Miguel de Icaza (Novell, Moonlight), Sam Ramji (Microsoft). They took questions which started the discussions, which got heated at times, but raised some great points. In hindsight, I wish I’d had found another panel discussion to go to.
All the sessions, including the keynotes (the Guy Kawasaki, Steve Ballmer keynote should not be missed) are available online now at http://sessions.visitmix.com in a number of formats. All that information is great, so in the end I really won’t miss any sessions I wanted to see, but the opportunities to meet the people I met aren’t available online. Here’s looking forward to Mix09 already.
Saturday, March 8, 2008
Tim and Steve's (not so) Excellent Adventure
After a wonderful trip to Mix08 in Vegas (update coming soon), Mr. Harman and myself were to have flown to home last night. However, the White Death didn't allow that, but thankfully Jeff had room for us. So, an extra night in Vegas, and rebooked plane rides for the next morning which would at least get us to Chicago. We left Chicago, with the lovely Mrs. Wingfield providing updates from home, hoping that we had a flight waiting for us at Midway that would take us home.
We got to Midway, I fired up my phone, text message from Wendy: "Your flight has been cancelled." So, a quick call to her with confirmation numbers and a hope that she could get through before we got off the plane. She did, but we had to go to the counter anyway. There our options were presented as: Stay in Chicago until Monday, or go somewhere else and try and get home. As much fun as two nights in Chicago sounded after four days in Vegas, we were ready to come home...so off to Indy!
Once in Indy, we got a rental car (a Grand Prix for you scoring at home) and have made it to a Holiday Inn about 30 miles east of Indianapolis. The hope is tomorrow the snow is cleared off I-70 and we can get back to Columbus.
If not, we have our very own version of Planes, Trains, and Automobiles..."THOSE AREN'T TWO PILLOWS!!!"
UPDATE: Tim and Steve's excellent adventure came to an end yesterday (Sunday the 10th) around noon. We made the drive in from Indy pretty easily. There were a number of cars in the ditch, mostly four wheel drives. Theory was the driver thought he/she was invincible and learned four wheel drive does not mean four wheel stop. The hairiest part of the journey was navigating German Village streets.
We got to Midway, I fired up my phone, text message from Wendy: "Your flight has been cancelled." So, a quick call to her with confirmation numbers and a hope that she could get through before we got off the plane. She did, but we had to go to the counter anyway. There our options were presented as: Stay in Chicago until Monday, or go somewhere else and try and get home. As much fun as two nights in Chicago sounded after four days in Vegas, we were ready to come home...so off to Indy!
Once in Indy, we got a rental car (a Grand Prix for you scoring at home) and have made it to a Holiday Inn about 30 miles east of Indianapolis. The hope is tomorrow the snow is cleared off I-70 and we can get back to Columbus.
If not, we have our very own version of Planes, Trains, and Automobiles..."THOSE AREN'T TWO PILLOWS!!!"
UPDATE: Tim and Steve's excellent adventure came to an end yesterday (Sunday the 10th) around noon. We made the drive in from Indy pretty easily. There were a number of cars in the ditch, mostly four wheel drives. Theory was the driver thought he/she was invincible and learned four wheel drive does not mean four wheel stop. The hairiest part of the journey was navigating German Village streets.
Subscribe to:
Posts (Atom)