Tech Blog

Jay's Technical blog

Getting the "unwashed" (aka "blue collar coders") to unit test

23 September 2008
Jay Kimble

[WARNING! This is an archived post and as such there may be things broken/missing here.. you have been warned.]

 

Roy Osherove has a great post on making TDD more accessible (which I would be remiss to mention that I am not really a part of the TDD movement except as a outsider/skeptic). There are a bunch of additional comments/posts in this regard which I won’t bore you with. You either got here because my post got linked to Roy’s thread or you are a regular reader here.

I was actually encouraged by Roy’s thoughts(again). He really gets it (I mean the reason why blue collar developers don’t do TDD). It’s all reminiscent of something I heard from within the security culture:

If it isn’t secure by default then... it isn’t really secure.

For instance, MVC was a web framework talked about by a bunch of people but no one REALLY used it until RAILS did it and made it easy to do (at least that’s my guess). In the ASP.NET space there have been alternative web frameworks (mostly MVC), but until MS did an MVC framework that was easy to use everyone used any web forms (you could have used an alternative ASP.NET Web Framework you know).

Improvements??

When I was at CodeBetter, I remember a lot of people complaining about how MS made it easy to develop crappy code using all kinds of ugly evil drag and drop mechanisms (DataSets and DataGrids come to mind).

As I look back on it, if that crew had decided let’s make it easier to build testable code by releasing a bunch of templates and making improvements to the testing frameworks (an add-in for VS that auto-creates class methods/properties while I’m writing test code would have been awesome). It could have even used mocking frameworks to determine what calls should be made in those properties/methods and add comments to that effect... This would make testing easier and would encourage test first.

You see there’s a way to get better code written, but it involves creating tools that make it easier to write good code (so "why would I want to write bad code... it’s easy to write good code"). I know for some of this won’t resonate. I fear that some love being "l33t" and so as long as coding is hard they feel like they are at the top of the food chain.

A Personal Experience

Chad Myers and I chatted a few weeks ago (or was it last week) in email about the testing I was doing. He really wanted me to post about my experience here. So, while I was being called out on my post where I was talking about SpDD, I was writing MbUnit code that looked like this:

  1: [RowTest("'A' Must Be False When Settings Object DisAllows 'A' For Customer")]
  2: [Row(true, 1, 2, 3, 4)]
  3:publicvoid A_Must_Be_False_When_Settings_Object_DisAllows_A_For_Customer(
  4:bool expected, int parm1, int parm2, int parm3, int parm4)
  5: {
  6:// Set up conditions
  7:     Assert.AreEqual(expected, SomeObj.SomeMethod(someSignature[]), "");
  8: }

I did this for something in my day job that absolutely had to be correct. Quality had to be 100%. The class under test had a bunch of rules (specs) that had to be tested. It had to be right... no questions asked, and having a regression suite of tests was an added benefit (it would never be wrong).

While I didn’t use classic DI, I was pretty close (so I could have mocked every dependency if I wanted to with minimal effort). Anyway, the net result was great. I have a set of regression tests and confidence that my understanding of the spec is covered with tests (so the end result should be a quality class that does what I would expect it to do).

Anyway, I’m really ashamed of one thing though. I’m afraid to admit that it took entirely too long IMNHO (Shawn C. don’t freak... it was a critical need): 1.5 days roughly.

Things like PEX may have helped a little, but the truth is I didn’t have time to learn a new tool (so I have no idea how quickly I could have done it with PEX)... I know, we never have the time. There are also tools out there for auto-gen’ing tests, but those aren’t that great either.

A Change

Something needs to change in this space for adoption to take off. Believe it or not I hope something does. The idea of a suite of regression tests sounds awesome to me... the idea that I have to write that test code isn’t quite so appealing... it either has to be easier to write tests or writing tests needs to help write code for me. At least that’s a suggestion.

As previously mentioned, I am not a TDDer. I’m a guy who gets some of these Alpha Geek ideas, but I’m more a "Beta Geek." I have one foot in the blue collar developer corner and one foot slightly over the line toward cutting edge developer... I try to walk the line and find better ways of doing things which is why TDD has me somewhat hung up (I like tests and the net result... but I don’t like the effort involved). I know TDD is about something else as well... but for me the benefit is the regression suite... all other things are simply window dressing appealing to an unknown "best practices" authority.

[That’s another rant in and of itself... the whole "best practices" thing.... who’s defining this? You guys sometimes need to do a better job with that... quoting "best practices" is like saying "it’s better because I said so." At least that’s what most of us hear... if you are going to use it then quote your authority.... at least if you say "Fowler said" then I can determine if "Fowler" is an authority I respect, and whether he carries weight with me].


Dependency Injection (DI) with Generics (or maybe not)?

18 September 2008
Jay Kimble

[WARNING! This is an archived post and as such there may be things broken/missing here.. you have been warned.]

[I am not the post boy for doing DI; I’m on good record for seeming to be against it, but I was reading an article on DI (yes, I read up on a number of things that run counter to my beliefs... I’m a thinker, so I think debate is a good thing and learning about the stuff outside your normal realm is a way to better yourself).]

I don’t think I’ve ever seen anyone talk about this and I did it recently. Basically you create a class like this:

  1:publicclass MyClassWithADependency<T> : SomeBaseClass where T:ISomeInterface,new()
  2: {
  3:     T _dependency;
  4:public MyClassWithADependency()
  5:     {
  6:         _dependency = new T();
  7: 
  8:// Use _dependency in the rest of your code
  9:     }
 10: }

If you are a TDD guy (or are familiar with unit testing), you have just enabled a whole scenario of things. Mind you have I have no idea how well this works with an IOC library (Ask Jeremy Miller or one of those guys), but the idea really has some merit for me (although I won’t be doing this everywhere).

In my case I am preparing for an expansion on a library I just wrote for work. It has something to do with reading Excel documents with FarPoint Spread and importing the data... what quickly came to light is that there will very quickly be a number of new requirements for our app that use Excel imports (so new data, so parsing mechanisms). BTW, our mechanism uses FarPoint to generate an Excel export file that is used by our users for data entry.

Anyway, I wanted to keep much of my parsing routines, but merge in new data structures. Injection via generics works great. I was even able to derive a new class based on a specific generic like this:

  1:publicclass MyNewClass : MyClassWithADependency<ClassThatImplementsISomeInterface>
  2: {
  3:public MyNewClass() : base()
  4:     {
  5:     }
  6:// Rest of your definition goes here
  7: }

Testing??

Since I’m not a TDD guy nor do I use Automated Test tools like MbUnit on a heavy basis, I will defer on this one. I will rely on someone like Chad or one of my regular readers to do it for me.

[Of course this example may be totally "whack" in which case tell me, please...]


TUX First Meeting wrap up

12 September 2008
Jay Kimble

[WARNING! This is an archived post and as such there may be things broken/missing here.. you have been warned.]

I am proud to say that our team pulled together our first meeting ever without any hitches that I know of. Most people found it fairly easily (despite my probably insufficient instructions). We had about 28 people (I think) show up.

As you may know (or you may not because you missed it), I spoke at the first meeting on an in depth talk on the MS Ajax Client Script enhancements (we’ll try not to get quite this heavily "developer-centric" in the future). We gave out the MSDN Premium that Bill Reiss donated to us and Chris Faulhaber won it. Feedback from the surveys was great and we’ll be using that data to help improve ourselves (watch the blog here or hopefully the one on the new site once it’s ready). The new site is at www.tampaux.org (and I know I keep saying it should be live soon... and well it should be live soon)

Joe Healy also blogged about us. Joe will probably have some more pictures (and I know we have some pictures on our site as well)

Anyway, we look forward to seeing you next month on October 8th at Answers Systems at 6:30 ("Same UX-Time, Same UX-Channel"). Bill Reiss (MVP-Silverlight) will be doing a presentation on Silverlight which promises to be a little more heavily design. We’re all looking forward to seeing you.

If you have an ideas, feel free to use the contact form on my blog to let me know... even if you want to criticize me. Please do. We want to make this group great!


Why I am one of the worst programmers on the planet (in some circles)?

11 September 2008
Jay Kimble

[WARNING! This is an archived post and as such there may be things broken/missing here.. you have been warned.]

First of all, we had a great turn out at the first TUX (Tampa User eXperience) User Group last night (more on that in another post... I’m still pretty exhausted).

I got to meet someone last night that I have maligned (sort of) in my blog. I hope he took my comment in the levity that it was meant to be taken. I told him that "everything is your fault" once you leave.

It’s an adage that I have told others and it is very true. It’s easy for the new guy to come in and say... all the code written before I got here is crap (NOTE: that is not what I said in my current position and I tend to try NOT to say that). Everything has a context that as the new guy you don’t have. And it also is very easy for someone to say "yeah, that last guy screwed that up," because the alternative is that "well, I contributed to the problem that is giving someone else pain" is just not something most people are willing to own up to.

So that said... I can tell you that I have built a lot of code under duress that quite frankly sucks. I’d hate to be you if you are maintaining it. I have also built stuff (in the past) that was a bad pattern choice for a particular problem. I did what I did because a) I wanted to use technology such and such and this problem came close to fitting, or b) I was flat out bored and wanted to do something different. I believe I have outgrown that... I tend to bug my peers a lot with "What do you think about doing this this way?" Mainly because I don’t want to repeat some of my past sins...

FWIW, if you get mentioned on my blog indirectly (I really do try to somewhat keep who I’m talking about anonymous... I’m not trying to ruin your career), its probably because I found a really cool solution to a problem that resulted from your solution which for whatever reason didn’t take something into account. Please, don’t take it personal... read up on what I did and offline tell me what you think. Maybe you might want to know "what happened?" I’ll be more than happy to tell you.


GrDD Refactored...

10 September 2008
Jay Kimble

[WARNING! This is an archived post and as such there may be things broken/missing here.. you have been warned.]

You probably think that GrDD AKA "Git 'R Done" development is a joke. And in some respects it is, but the concepts behind it are not. I have been talking to some friends and I think I have a pretty good idea of what we are talking about. Now mind you I’m not a methodology guy. I want to stress that. I’m just trying to get this out of my system.

Before I proceed, I know there are some "agilists" out there who are subscribed because they can’t wait to pounce on an idea that is counter to their ideas (and since TheRuntime.com seems to be the center for "Alt ALT.NET". Please resist the urge. I know it’s hard to believe that there are a not a few of us who are skeptics, but there are (and some way smarter than me). If anything I’m trying to present an alternative idea that might lead people towards your thinking and maybe make some of it more palatable for other skeptics.

Just to make myself clear to y’all, I typically tolerate all kinds of dialog and even invite it... but if you are planning on flaming all I can say is do it elsewhere... if you have something you think adds to my dialog then please feel free... If you aren’t "agile" then you are really invited to take part... I’ve had some ideas since my CodeBetter days that got shouted down back there, and I think it has merit for those practicing more of a GrDD <smile /> practice.

GrDD refactored = ClDD

ClDD is really a better acronym for what I have been touting. Client Driven Development or simple ClDD (could be pronounced "Cloudy" which is how it often starts). The idea here is focusing in on the client’s needs and working hard toward achieving that goal with minimal additional distractions. That may mean developing a web site with MS Access at the core of the site (I’ve done it/am doing it again)... It doesn’t mean that you don’t try to talk the client out of it... just that you are doing what the client ultimately wants done (and you aren’t building extra stuff beyond what is needed). I know that ruffles the feathers of some agilists, but the idea is simply put that you have to understand what the client needs and you make tradeoffs to meet the deadline. (BTW, this is what makes Billy Hollis an honorary GrDD prophet... see Jacob’s post back here... he gets it IMNHO). FWIW, This is really a re-hash of the RAD methodology from the turn of the millenium (or thereabout).

What about Quality?

[This is one I’m poking around with right now... it’s the idea from way back in the CodeBetter days. I’ll forego using the agile name, but it will be apparent what I’m re-purposing.]  One of the things I really want to do more of is POUT (Plain Old Unit Testing). My problem could be resolved by answering the question "What should I test?" Some would say "Everything!" But I think there is a diminishing set of returns. Testing an empty constructor or testing a simple property seems like waste of time to me.

Enter SpDD

The idea that I have come up with involves recording the specs or rules of a system... call them
"stories" or use cases or simply business rules and build tests around as many of these as is possible (as long as you have the time to do so). Now this doesn’t produce 100% code coverage nor does it always produce 100% testable code (which to some is important)... it might represent Test First written code or it might represent Test Last written code... what I want to be able to do is determine that my code is living up to the spec, and have a set of regression tests to prove this to myself (I’m not sure what I think of the testing tools in this arena at this point... verdict is still out for me).

BTW, SpDD is pronounced "Spee-Dee."

[Alright Rob, Jacob... what do you think? Poke holes in it as it’s just an idea at this point... not something I’m doing, yet]