Code Obsession

StructureMap

noreply@blogger.com (David Adsit) — Sun, 10 May 2009 08:06:00 +0000

I've been using a ServiceLocator class for IoC for the last year and a half. Never really got the point of the containers until the last week. We had a strange API requirement for a component for another group. I didn't agree with it, but basically, they wouldn't let us do constructor or setter injection of the dependencies. Let's not get into that, but lets just say that grabbing StructureMap 2.5 and throwing it into the mix saved me a ton of time. Also, I now get it. The container took what would have been 30-50 lines of ServiceLocator.cs and made it less than a dozen. And they were very clean and easy to read. And since you can initialize the objectfactory where ever you need to, I was still able to test those blocks and get a high level of coverage.

I have been using RhinoMocks since I first started TDD and I am pretty fond of it. The AutoMocker in StuctureMap has forced me to shift from the using(mocks.Record()){}... style to the Arrange-Act-Assert style. I'm comfortable with the other style, but I will admit that this would be easier to teach to beginners (provided you leave the AutoMocking out of it, of course!)

Anyway, I wonder now if I should spend a little time looking into Castle Windor and see which I prefer. . .

Training Materials...

noreply@blogger.com (David Adsit) — Sun, 10 May 2009 07:41:00 +0000

So after realizing that the 10,000 page book on ASP.NET is better as a reference than as a training guide (seems like someone said that several times before we started this book), we voted on whether to read Clean Code or Refactoring to Patterns next. Considering the make up of our team and the state of our code, I lobbied fairly hard to get Clean Code in front of everyone before we dive into patterns (again).

It seems that a lot of our more experienced developers are pretty resistant to reading Clean Code. I think there is a mentality that "the way I do it is right and there is no need to change or improve." I think that is pretty sad. I read Clean Code a few months ago, and it has helped me vastly. It is amazing how much more maintainable my code is now.

Anyway, I think that for my team (we have not quite a 3 to 1 ratio of juniors to seniors) we need to have a purpose to our refactoring. Making our code more readable and reducing our coupling seems like a pretty worthy purpose. I shudder at the thought of a couple of juniors pairing together and going pattern crazy on some code block that should be simple and straight forward. Don't get me wrong, I think that design patterns are a great idea. I look forward to reading Refactoring to Patterns when it comes up in my personal queue. I just prefer that our mentoring/training take a more methodical approach.

When I finally convinced my team to start using MVP, I had juniors come up to me and tell me that "this new pattern doesn't make my code any more testable at all!" When I looked at the implementations, they had usually done a Supervising Controller and but all of the business logic in the view. Go figure. When you implement the wrong pattern, or misunderstand the pattern, you don't see any of the benefits of the pattern. It seems likely to me that reading a patterns book is going to take us right down that path again.

Ah well, democracy worked and the correct book was selected.

Friends don't let friends leave code dirty

noreply@blogger.com (David Adsit) — Sat, 07 Feb 2009 02:27:00 +0000

So it turns out that I prefer writing code to writing about code, but I just finished reading Uncle Bob's "Clean Code: A Handbook of Agile Software Craftsmanship." I highly recommend it. This book very clearly addresses the large majority of the issues I face every day at work. Our environment is full of code that works, but was never finished. In other words, the code is a mess. I'm passing the book around work hoping that it will help spread the vision. Hopefully, we pick it up as one of our next training books for the whole team.

Software Design Speak

noreply@blogger.com (David Adsit) — Tue, 11 Nov 2008 05:12:00 +0000

I went to SD Best in Boston, and I have been thinking a lot about what made some of those sessions. While I continue to gather my thoughts about that experience, here is something to keep you entertained:

Often I say things to my coworkers about software design that are the result of a lot of research and time spent in contemplation. The problem is that I usually just give a 1 or 2 sentence summary of the idea and expect my coworkers to just get it. Or at least they could just assume I am right and we can move forward from there (too bad that doesn't ever happen).
I think that the biggest problem I have communicating my thoughts and ideas is one of nomenclature. We use a lot of terms that are heavily overloaded and can have a lot of definitions. I think it will help if I define some terms as I understand them based on my study. I have shared this with my coworkers and invited them to comment and add their own definitions. So far, there are no takers. I'm pretty sure none of them have even read it. I guess they would rather argue with me than speak a common language.

Anyway, here goes the Dictionary of Dave as well as what I think of as the more traditionalist approach to these topics.

Business Object
My Opinion - A business object is any representation of a business rule, requirement or concept as a code structure. Examples include: ThankYou page, Order object, RxDAO repository, etc.
What I think of as a more traditionalist view - A business object is a specific type of component that fits between the UI and the database. These objects have a lot of functionality like loading themselves from the data layer, saving themselves to the data layer, executing rules validation on themselves, etc. Basically, these are buffers that completely isolate the UI from the Database. They most often (if not always) instantiate the data layer object(s) that they need to perform persistence work. Examples include: most of the classes in the CTAC.Core namespace (not child namespaces), anything CSLA, most objects that I wrote between 2002 and 2006, etc.

Domain Object
Dave - A domain object is a specific type of business object that encapsulates a business concept. Often these are referred to as Entities when reading about code. They are composed of primitives and other Domain objects. They enforce rules related to the data they represent and provide a simple, yet specific (read type-safe) way to deal with that data. Examples include: Rx, Customer, etc.
Traditionalist - What's a Domain object? Did you mean data transfer object, cause we have plenty of those, if you need to push an instance of a business object somewhere over a wire or something.

Service (Module)
Dave - Well, this is a fairly simple and ubiquitous type of object. Basically, Services are any object that performs work on Domain objects. Common types of services are Repositories and Presenters. Since the Domain objects have no knowledge of persistence, UI or any other external component, the Services must perform these types of actions on the Domain objects. Services should always implement an interface to loosen the coupling, allow for mocking and facilitate inversion of control. Examples include: the SessionState wrapper, all the DAOs, etc.
Traditionalist - All of this functionality is encompassed by the business objects, so there isn't really a need for these Services of which you speak.

Service (SOA)
Dave - An SOA service is basically a business unit. It can be implemented using any type of design or architecture and doesn't need to share any of these decisions with its sister Services. It can have a separate data store of a different type than its sisters also. Basically, a service is an application or business silo that exposes part of its functionality to other parts of a company for their consumption. Because it owns the rules, logic, data, etc for the entire process, it can share its functionality by exposing web services, COM+, MSMQ or any other communication method. Examples include: the Email Sending Service and the Tax Service (I think).
Traditionalist - Well, this is easy! It is anything that has a web service, duh! The more the better! In fact, every single business object should have at least one web service that is somehow related to it. We should probably implement the Data Layer as web services too. That way, we can use those Data Transfer objects more. Yippee!

n-Tier Architecture
Dave - This is a step in the evolution of software development and it was a big one. Before this, everything was procedural or event driven and we didn't have a lot of structure. N-Tier gave us some structure and helped protect us from the retardedness of having data access in the UI or HTML generated in a stored procedure, etc. There are some problems, but every solution brings problems and overall, we were much better off than ever before.
Traditionalist - What do you think we have been talking about this whole time? N-Tier is the only way to make software. You have to have layers, just like an onion...or is it a cake? Anyway, the layers protect us and wrap us in warm goodness. Layers rule and we should try to have at least N of them.

Modular Architecture
Dave - This is the next step in evolution. The tiers were heavy and sometimes seemed contrived or difficult to work with. We had separation of layers, but we didn't really gain much by way of decoupling. In fact, we were often more coupled than before we adopted n-Tier because creating the UI objects automatically created business and data layer objects. The basic idea of the Modular software design is to create Domain objects and Services that are self contained and can be used independently. You don't restrict who has access to what; you just make sure that each piece does what it says it will do. When you need a thing, you grab that thing and use it (hopefully using the dependency injection pattern). This means that sometimes a UI component (like a Presenter) will have a reference to a Repository or some such. Under n-Tier, it was considered a huge rules violation for the UI to even have knowledge that a data layer (or data service under my definition), but under the modular design, there is no such restriction, so no problem. Components are loosely coupled and can be assembled as needed to create whatever components or features the business requires. No heavy infrastructure has to be created to make use of the components you need. Part of the advantage to this design is that you can create software vertically in slices rather than horizontally in layers (meaning that a feature can be implemented from UI to data as a single story). Because of the fact that every component is separate and loosely coupled, the components can be developed and tested independently. This allows for a more agile approach to development and results in software that is more maintainable.
Traditionalist - I'm not sure what you are even talking about here. N-Tier is the final evolution of software design. There is no need for anything beyond that.

Paired Programming - Who? What? When? Where? Why? and How? . . .

noreply@blogger.com (David Adsit) — Mon, 20 Oct 2008 01:18:00 +0000

Cheese Pairing for this Post: blue stilton
[ugh. much like the meeting, this cheese leaves me irritated and with a slight taste of vomit in my mouth that I can't seem to shake for the rest of the day]

So the other day at work, we had a meeting to discuss Paired Programming. The Outlook invite said something about "Improving Paired Programming," but from the time we started, it felt a lot more like "Bitching about Paired Programming." At one point, while we were listing a few things we like about it, one of our managers actually said, "Let's stop giving text book answers and talk about the real world." As I am a huge fan of the technique, I have to vent/rant a little and get my opinions out there.

What (is Paired Programming)?
Just so we are on the same page, allow me to assert some preconditions for the follow discussion. When I say paired programming, I am talking about 2 developers, 1 computer, 1 story/bug/issue to work on. I prefer to have 2 keyboards and 2 mice as well, but that is a matter of personal taste and I can understand why some people prefer to only have one of each. Anyway, that is it. That is all I am talking about. Two programmers, one driving, one navigating (when done properly) or sleeping (when not done properly).

Why (do Paired Programming)?
This is the big one, eh? For those of us who have been doing it for a while, it seems like a no brainer, but let's review for the heck of it.

Let's start with the reason that is least important. We have a business requirement that all production code be reviewed before going to QA and paired programming satisfies that requirement. I called this the least important reason why to do paired programming, but it is actually pretty significant. The alternative is that we perform code reviews after the code has been written. Scientific studies (I read a couple somewhere. . . .you have google, you find 'em) as well as lots of personal, anecdotal evidence prove to me that code reviews after the fact are a less effective way of preventing faults from reaching QA. Time is always a constraint during a review. How many minutes does it take to properly cover all the enhancements, refactorings and reasons behind them that went into 35 hours of work in the last week? And who wants to take that time when they have their own 35 hours of work to get done? If it compiles and passes the tests that the developer wrote for it, that has often been enough to pass any code reviews I have seen. And, since we already mentioned time constraints, if the review happens at the end of the cycle, and the reviewer(s) see an architectural or design flaw, do they mention it? Do you just let it go to get the feature out and add that to the technical debt pile? Do you throw it back to the developer, or another developer, to rework it for the next iteration? These types of issues are reduced when you have 2 sets of eyes on the thing throughout.
Two heads are better than one! I just touched on this a little, but let's face it; two developers looking at the same issue are going to come up with a better design/solution than one developer. If they see the solution differently, they can discuss it and come up with something better than either would have done alone. Even if they have the same solution, that at the least is confirmation that it is a workable one.
It is less likely that 2 people are going to break the rules than one alone. Let's be honest, how many times have you been under a deadline and, even though you know that you need to test, and you are totally committed to working test driven and then you hit up against some legacy code that is just not designed for testability, and you just say, "Screw it, I don't have time to do this right! Add it to the technical debt. QA will do integration testing on this anyway, right?" If your pair is sitting there, you will probably just man up and do it, right? Another flavor of this is coding standards. If your company uses one that isn't the same as you use at home, you may just slip into your own habits. A pair is going to say, "What are you doing?" before you get to the second private field without an underscore. I've tried, honest, but I'm just not feeling that underscore, guys.
This is a simple one, but important. That second set of eyes is going to notice your goofs quicker than you are. If you are really in the groove and you instantiate a CardProcessor where you needed a CartProcessor, a pair who is awake will take away the keyboard and call you a moron or at the very least ask you why you are doing it. Even when it isn't a logic flaw, but just something that the compiler or the tests will catch, it is still quicker to get it before that, eh?
Here is a BIG one: Training. None of us knows everything. I know, that hurts to hear, huh? Well, I said it so I think I may need a Vicodin. But let's face it, there are so many things to know from CSS, JQuery, ASP.NET, C#, T-SQL, TDD, not to mention the Domain itself, that having someone there who may have more experience in at least part of one of these areas can be a big benefit. The good thing about it is that you can just ask them right there and then you own the knowledge too. You don't have to go in search of that-one-guy-who-works-wierd-hours-and-lives-in-a-cave-and-drinks-too-much-Monster and admit to him that you don't know why the subprocessor written in assembly when you were 3 years old is returning a certain value when you pass it the following parameters. Your pair has that knowledge already. . . .or at least he has your back when you are in the C-monster's lair.

In summary, the whys include: Cause I said so!, Code Reviews Suck, 2 Big Brains > 1 Big Brain, Standards, You Can't Type, It's Not a Ubiquitous Language if Only One Person Speaks It.

How (should you Pair)?
There are lots of ways. Just do it comes to mind. Recommendations I have are as follows:

Change pairs often! Daily ought to be enough. Twice a day if you work 4-Tens (lucky jerk). This rule applies even when you are working on a multiday story. I would say even especially when it is a long story. I would put 2 guys on it on day 1, take one of those guys off on day 2 and replace him with someone else. On day 3, take the remaining guy from day 1 off and replace him. There are several advantages to this. Getting stale means getting sloppy. Bringing on the new guy means explaining what you did. This will probably happen pretty quickly. . . .Unless he asks you, "Uh, are you high? Why did you do it like that?" Then you get to hear his solution. Between where you were and where he thinks you should be, you may find a better solution. Good thing he showed up on day 2, rather than day 25, huh?
Also, change pairs often! You know that one guy you can't stand? Working with him all week could make you even crazier than you already are, eh? It is worth noting that you are that guy, at least to one member of your team.
Team Leads ought to select the pairs. Or at least be involved. The reason for this is that, given the option, we are most likely to just work with our friends every day. Let me tell you, that is fun. Also, it is fairly inefficient when it comes to knowledge transfer. Team leads ought to be making pairing assignments based on some overall plan for the team. Certain members may be weak in some areas and should be paired with those who are stronger in those areas to bring them up to speed. They also may chose to pair a couple of seniors together on particularly challenging issues, at least for the initial design. There may also be some constraints, such as one on our team that states that a pair may not consist entirely of contractors. Assigning the pairs will also cause more mixing and this can help the team members become closer and make communication easier and more open.
When pairing, the more knowledgeable member should be the one navigating and writing the tests. By having the guy who knows what is going on write the tests, he can make sure they are correct, and he can also explain to the other guy the why it needs to be done in a certain way. This means that you will be changing drivers often. Coder A writes a little test, Coder B writes a little code. Repeat. When you are of equal knowledge on the subject, just mix it up. A writes a test. B implements it. B writes the next test. A implements it. Repeat. By swapping drivers often, you make sure that you are both involved.
Ask Questions! This shouldn't even need to be said, but it does. Whether you are the junior pair, senior pair, new guy on the team, expert with 20 years experience, it doesn't matter. That guy sitting next to you knows something you don't. He may be using a hotkey you don't know, or possibly a design pattern you aren't familiar with. Big or small, he has some knowledge you need, and you need to ask him for it. Don't be afraid to ask for it.

In summary, the hows include: Change Pairs, Change Drivers, Ask Questions.

When (should you Pair)?
This depends on your environment. I say, as much as possible. At the very least, for everything that is going into production. For us, we start pairing right after Morning Standup and pair until the end of the day. Since this is about 7 hours for us, that means only 35 hours a week of pairing. I heard some of the guys whining about how they never get a chance to do any personal research on the domain, tools, etc, and I gotta say, that is pretty weak, 'cause we really are supposed to work 40+ hours a week. Since all of our meetings fall inside the pairing hours, it seems like there are at least 5 hours a week when you could be doing personal research, or writing more tests (as long as you aren't writing any production code), or asking questions, or whatever. Do you need a list of things to research that you may not be an expert on? Start here: .NET 3.5 framework, ASP.NET, Ajax, JQuery, CSS, C#, TSQL, NAnt, CruiseControl.NET, TDD, NUnit, RhinoMocks, WatiN, ReSharper (and its plugins), TFS, Better source control than TFS (why can't we all just use SVN?), GoF Patterns, Patterns of Enterprise Architecture, Inversion of Control and the Dependency Injection Pattern, .NET MVC framework, Linq, MFP, MFC, MVP, Our Domain. If you are an expert on all that, you are hired 'cause we don't have one on staff. On second thought, you are not hired, cause you are lying. And if you aren't lying, and you really are an expert on all that, we can't afford you. Anyway, there is a lot to learn and you don't need to pair to do it.

Where (should you Pair)?
I think you ought to pair in the same room with the rest of the team. This allows for easier communication and greater camaraderie. You know how you don't know everything? (Sorry to bring that up again) Well, your pairing partner doesn't either, so it might help if you don't have to go trekking around to find the guy who does. I know that this doesn't work in every environment, but if you can do it, I think you should.

Who (should Pair)?

Simple. Everyone who is working on production code.
Teams who want to make high quality software quickly, with few defects.
Also, everyone who wants to learn from another member of the team.
Anyone who thinks they know something worth teaching to another member of the team.
Umm, if you aren't in one of those categories, do you even have source code access? Please say no.

Summary
Paired programming is an excellent methodology if you want to create a software package that is maintainable. Done right, it enhances the quality and the velocity of software development.

Well, there's my ten cents, my two cents is free. . .

Sorry. If you made it this far, you didn't deserve an Eminem quote. I really do apologize.

Live Templates . . .

noreply@blogger.com (David Adsit) — Wed, 08 Oct 2008 13:00:00 +0000

Cheese Pairing for this Post: Beecher's One-Year Aged Flagship Cheddar
[mmm. that's tasty]

Live templates in ReSharper are an excellent time saving tool. They allow you to put code that you use over and over into a shortcut that you don't have to retype it all the time or maintain it in files external to Visual Studio.

I have a few that I've created to make my life easier.

test

[Test]
public void $TESTNAME$()
{
 $END$
}

rhino

[Test]
public void $TESTNAME$()
{
 $END$
 using(mocks.Record())
 {
  
 }
 using(mocks.Playback())
 {
  
 }
}

tostring


public override string ToString()
{
  MemoryStream memoryStream = new MemoryStream();
  XmlSerializer xmlSerializer = new XmlSerializer(GetType());
  XmlTextWriter xmlTextWriter = new XmlTextWriter(memoryStream, Encoding.UTF7)
                                    {
                                        Formatting = Formatting.Indented,
                                        Indentation = 1,
                                        IndentChar = '\t'
                                    };
  xmlSerializer.Serialize(xmlTextWriter, this);
  memoryStream = (MemoryStream) xmlTextWriter.BaseStream;
  UTF7Encoding encoding = new UTF7Encoding();
  return encoding.GetString(memoryStream.ToArray()).Replace("><", ">\r\n<");
}

This last one works great for figuring out where the differences are when you get an expectation error in one of your tests. Just throw that XML string from the test output into WinMerge and done. Also, I would like to point out for anyone who isn't aware, there is a hotkey in R# to automatically implement IEquatable and override Equals: Alt+Ins, E. Brilliant stuff. The only issue is that you need to update it (Alt+Ins, E will do that too) every time you change your object. That helps with those stubborn objects that tend to get compared by reference when you want to just compare their values.

Sorry about the delay on this post. Apparently, my blog was flagged as spam for a while. All is better not though.

ReSharper Code Cleanup . . .

noreply@blogger.com (David Adsit) — Mon, 06 Oct 2008 13:00:00 +0000

Cheese Pairing for this Post: Jarlsberg
[my favorite emmentaler; jarlsberg is excellent for snacking or sandwiches]

ReSharper will automatically clean and organize your code for you according to your specifications. The default specs are great; however, I find that I like to put my methods, field, etc in a slightly different order. Here is the config that I use. The only enhancement I still want to add is sorting auto properties before properties that have a backing member rather than intermixed. I haven't figured out how to accomplish that yet, so if anyone knows, please post the answer in the comments, thanks.

Without further ado:


<?xml version="1.0" encoding="utf-8" ?>
<Patterns xmlns="urn:shemas-jetbrains-com:member-reordering-patterns">
<!--Do not reorder COM interfaces-->
<Pattern><Match><And Weight="100"><Kind Is="interface"/><HasAttribute CLRName="System.Runtime.InteropServices.InterfaceTypeAttribute"/></And></Match></Pattern>
<!--Special formatting of NUnit test fixture-->
<Pattern RemoveAllRegions="true"><Match><And Weight="100"><Kind Is="class"/><HasAttribute CLRName="NUnit.Framework.TestFixtureAttribute" Inherit="true"/></And></Match>
<!--Setup/Teardow-->
<Entry><Match><And><Kind Is="method"/><Or><HasAttribute CLRName="NUnit.Framework.SetUpAttribute" Inherit="true"/><HasAttribute CLRName="NUnit.Framework.TearDownAttribute" Inherit="true"/><HasAttribute CLRName="NUnit.Framework.FixtureSetUpAttribute" Inherit="true"/><HasAttribute CLRName="NUnit.Framework.FixtureTearDownAttribute" Inherit="true"/></Or></And></Match></Entry>
<!--All other members-->
<Entry/>
<!--Test methods-->
<Entry><Match><And Weight="100"><Kind Is="method"/><HasAttribute CLRName="NUnit.Framework.TestAttribute" Inherit="false"/></And></Match><Sort><Name/></Sort></Entry></Pattern>
<!--Default pattern-->
<Pattern RemoveAllRegions="true">
<!--delegate-->
<Entry><Match><And Weight="100"><Access Is="public"/><Kind Is="delegate"/></And></Match><Sort><Access Order="public protected internal private" /><Name/></Sort></Entry>
<!--enums-->
<Entry><Match><Kind Is="enum"/></Match><Sort><Access Order="public protected internal private" /><Name/></Sort></Entry>
<!--constants-->
<Entry><Match><Kind Is="constant"/></Match><Sort><Access Order="public protected internal private" /><Name/></Sort></Entry>
<!--static and readonly fields-->
<Entry><Match><And><Kind Is="field"/><Or><Static/><Readonly/></Or></And></Match><Sort><Access Order="public protected internal private" /><Name/></Sort></Entry>
<!--fields-->
<Entry><Match><Kind Is="field"/></Match><Sort><Access Order="public protected internal private" /><Name/></Sort></Entry>
<!--Constructors. Place static one first-->
<Entry><Match><Kind Is="constructor"/></Match><Sort><Static/><Access Order="public protected internal private" /></Sort></Entry>
<!--Destructors. Place static one first-->
<Entry><Match><Kind Is="destructor"/></Match><Sort><Static/><Access Order="public protected internal private" /></Sort></Entry>
<!--Instance indexers-->
<Entry><Match><And><Kind Is="indexer"/><Not><Static/></Not></And></Match><Sort><Access Order="public protected internal private" /><Abstract/><Virtual/><Override/><Name/></Sort></Entry>
<!--instance properties-->
<Entry><Match><And><Kind Is="property"/><Not><Static/></Not><Not><Kind Is="indexer"/></Not></And></Match><Sort><Access Order="public protected internal private" /><Abstract/><Virtual/><Override/><Name/></Sort></Entry>
<!--Methods-->
<Entry><Match><And><Kind Is="method"/><Not><Static/></Not><Not><HandlesEvent /></Not><Not><Kind Is="destructor"/></Not></And></Match><Sort><Access Order="public protected internal private" /><Abstract/><Virtual/><Override/><Name/></Sort></Entry>
<!--Event Handling-->
<Entry><Match><HandlesEvent /></Match><Sort><Access Order="public protected internal private" /><Abstract/><Virtual/><Override/><Name/></Sort></Entry>
<!-- event -->
<Entry><Match><Kind Is="event"/></Match><Sort><Access Order="public protected internal private" /><Name/></Sort></Entry>
<!-- operator -->
<Entry><Match><Kind Is="operator"/></Match><Sort><Access Order="public protected internal private" /><Name/></Sort></Entry>
<!--Class indexers-->
<Entry><Match><And><Kind Is="indexer"/><Static/></And></Match><Sort><Access Order="public protected internal private" /><Abstract/><Virtual/><Override/><Name/></Sort></Entry>
<!--Class properties-->
<Entry><Match><And><Kind Is="property"/><Static/></And></Match><Sort><Access Order="public protected internal private" /><Abstract/><Virtual/><Override/><Name/></Sort></Entry>
<!--Class Methods-->
<Entry><Match><And><Kind Is="method"/><Static/></And></Match><Sort><Access Order="public protected internal private" /><Abstract/><Virtual/><Override/><Name/></Sort></Entry>
<!--all other members-->
<Entry><Sort><Access Order="public protected internal private" /><Abstract/><Virtual/><Override/><Name/></Sort></Entry>
<!--nested types-->
<Entry><Match><Kind Is="type"/></Match><Sort><Name/></Sort></Entry></Pattern>
</Patterns>

Qualities of a Good Unit Test . . .

noreply@blogger.com (David Adsit) — Thu, 02 Oct 2008 13:00:00 +0000

Cheese Pairing for this Post: smoked gouda
[this is something great for every day consumption; try some on toast]

So I was looking through some of the documents I have used for presentations in the office and I thought this was an interesting one:

Atomic

A unit test should only test a small piece of functionality.

A litmus test is to ask if any part of the unit test could stand alone in a separate unit test.

Another feedback loop for your unit testing quality is the amount of time you spend with the debugger. If your unit tests are coarse, a test failure is more difficult to find. If the unit test exercises a small amount of code, the test failure cause can usually be spotted very quickly.

Order Independent & Isolated
There should never be an order dependency, intentional or not, between unit tests.

Problems arise when one unit test leaves some kind of dirty data lying around. Testing against a database or some sort of static cache is a common culprit.

Put evil, stateful things behind nice, deterministic mocks or stubs.

Intention Revealing

A unit test can, and should, be a valuable form of documentation.

Unit tests are part of the contract that software implements.

A unit test provides a sample of the expected usage of the code.

Excessive data setup can obfuscate a unit test beyond any hope of comprehension.

Easy to Setup
How easily can I set up an environment to run the tests? If the answer is "not very," I might never get the tests running.
As much as possible, decouple unit tests from external dependencies like databases and web services by using mocks or stubs. When you do test against an external dependency, the dependency better be setup correctly by the automated build.

Transactions . . .

noreply@blogger.com (David Adsit) — Fri, 26 Sep 2008 19:37:00 +0000

Cheese Pairing for this Post: 1-year-old, Cave-Aged Gruyere
[this is a great one that you can really enjoy every once in a while under the right circumstances]

So, this week a user story was assigned to me that said something like, "Make sure that we don't save and of the Order data if we can't save ALL the Order data." Immediately, I thought, "Sounds like time to add some transactional support to our (custom) repositories." So there I am adding some tests to the repositories solution that assert that I have some infrastructure in place to track all of the database connections, etc, when one of my co-workers says, "Why don't you just use TransactionScope?" This was new to me, so here is what I learned:

TransactionScope is a class built on the Microsoft Distributed Transaction Coordinator. It basically wraps up all that hard work of tracking and committing or rolling back transactions across multiple connections into an easy to use interface, like so:


void MethodWithTransaction()
{
    using(TransactionScope scope = new TransactionScope())
    {
        /* Perform transactional work here */
        scope.Complete();
    }
}

That's it. If you get to scope.Complete(), the transaction(s) commit. If you don't get there, the whole thing rolls back when the TransactionScope is disposed.

Ok, you knew that wasn't all there is to it right? You have to configure your SQL Servers to run the DTC components. I didn't do this as our OPS team already had it done. I did have to do some config on my machine though. Here are the steps:

Run dcomcnfg:

Right-click My Computer and open up the properties. Go to the MSDTC tab:

Click the Security Configuration button:

Those are the setting that work for me. I also had trouble with the firewall we used here at work, but our networking guys were able to resolve that as soon as I mentioned DTC.

In the (likely) event that you need more info, try these links:

Troubleshooting Problems with MSDTC

How To Use DTCTester Tool

Good Luck!

Getting started . . .

noreply@blogger.com (David Adsit) — Fri, 26 Sep 2008 19:28:00 +0000

OK, now that that is out of the way, lets talk about code.

I work in C# using Visual Studio.NET 2008 w/ReSharper. After working with ReSharper for the last year, I honestly can't imagine working without it, hence the inclusion as part of my IDE. Why don't I throw some buzzwords at you and then try to justify them: DDD, TDD, Agile, XP, IoC, RhinoMocks, nUnit, WatiN, Patterns, Patterns, Patterns... The list could go on. Years ago, I would have defined myself (as a coder) using the names of technologies (XML, HTML, T-SQL). Now I talk more about tools and methods than technologies.

I mostly work in ASP.NET targeting the .NET 3.5 framework these days at work, though at home, in my free time, I tend to be more desktop focused.

Well, this isn't a resume, now is it? I should just talk about the things that really interest me...

Setting the mood . . .

noreply@blogger.com (David Adsit) — Fri, 26 Sep 2008 19:12:00 +0000

I work in a shop that practices paired programming on all production code. While I quite enjoy this style and encourage it, I occasionally feel the need to check out from the team and get into a coding zone of my own. I find that heavy metal and punk rock help set up the correct mood for me fairly well. Here is the Pandora station I generally listen to: Code Machine.