Posted on 6/30/2009 10:25:21 PM by Justin Etheredge
The title of this post actually isn’t a question that I get asked very often. I think the reason that I don’t get asked this very often is because of two different reasons. The first reason is that people (and programmers especially) are embarrassed to admit when they don’t know something that they feel like they should know. Secondly, many developers out there think they know exactly what you are talking about when someone says “unit testing”.
Of those developers who think they know what unit testing actually means, I would be willing to bet that only about 10% really do. You see, the problem is that when most developers are asked to define unit testing they will say something like “tests that are run against a project using a unit testing framework”. That is kinda right… well… not really. It isn’t really right at all. In fact, calling frameworks like NUnit, xUnit, MbUnit, MSTest, etc… “unit testing frameworks” is inaccurate. They are instead “automated testing frameworks” which can be used to execute any number of kinds of tests. One of these kinds of tests just happens to be unit tests. There are also integration tests, performance tests, load tests, etc…
Okay, so what exactly is a unit test? It is a test which verifies a “unit”, or the smallest piece of an application which is able to be tested. Ideally, when writing a unit test in C#, you’d want to isolate an individual class and write tests against only its functionality. The developers doesn’t want to pull in external dependencies and doesn’t want to access external processes or services. Unit testing is all about testing small pieces in isolation.
Continue reading the rest of this post...
Posted on 6/29/2009 12:09:30 AM by Justin Etheredge
On Twitter the other day I had a short conversation (well, it wasn’t really a conversation since it was only about 4 tweets) with Jeff Cohen who is the author of Rails for .NET Developers. Which is, by the way, an excellent book and highly recommended. The conversation that we had was about the dynamic keyword for C# and its implications for C# developers.
Jeff expressed some concern for the keyword and its potential abuse among C# developers. His point was that if C# developers want to write dynamic code, then you need to use a language like IronRuby or IronPython, not try to inject dynamic code inside of C#. Thankfully, for the most part, I agree with him! However, I do think the dynamic keyword is a great thing because, most importantly, it allows interop between static and dynamic languages to be super easy. Without dynamic, we would have to use all kinds of nasty APIs to use an IronRuby object inside of C#. With dynamic I’ll be able to write code that looks like this:
dynamic irObject = GetIronRubyClass();
string resultValue = irObject.CallSomeMethod();
Which is pretty awesome, but how would that possibly work in a statically typed language? The short answer is that it wouldn’t. In order to accomplish this magic, whenever C# sees the dynamic keyword it generates IL that performs late bound calls against the object. Which means that in order to interact with a dynamic language, C# essentially becomes a dynamic language itself. So does that mean that C# is a dynamic language now?
Continue reading the rest of this post...
Posted on 6/18/2009 10:25:47 PM by Justin Etheredge
I gave a presentation tonight at the Charlottesville .NET user group on building testable applications. The presentation was focused around the Single Responsibility Principle and the Dependency Inversion Principle. We started off with a very simple app that we slowly factored out dependencies into their own class, and then implemented a dependency injection framework (Ninject) in order to resolve our dependencies. Then we implemented a mocking framework (Moq) in order to mock our dependencies to use in testing. The application was built in a series of steps, and by popular demand I have attached to this post the final result of the application refactoring! (Popular demand, ha!)
Anyways, unlike my previous experience, this talk went really really well and I got quite a bit of good feedback from the talk. I can’t wait to give the talk again, I really wish that I had submitted it to DevLink instead of one of the other talks that I am giving.
I wanted to thank everyone who came out to see the talk, I really enjoyed giving it! I can’t wait to give it at the Richmond .NET User Group in October!
Oh, and the presentation was only a few slides with just pictures. I didn’t attach it because it really makes no sense out of context.
Source for the test project updated with start and finish project
Posted on 6/15/2009 9:43:09 PM by Justin Etheredge
For loops have been our friend for so many years. I have fond memories of looping through huge lists of items imperatively bobbing and weaving to construct my final masterpiece!
for (int i = 0; i < items.Length; i++)
{
if (items[i].SomeValue == "Value I'm Looking For!")
{
result.Add(items[i]);
}
}
Look at that beauty. I am looping through a list of items, filtering them on some value, and then BAM! I get a result list with the values in it. Magic I tell you, magic. And then foreach loops came along and I realized how ridiculously ugly it was.
Continue reading the rest of this post...
Posted on 6/11/2009 11:01:20 PM by Justin Etheredge
In my last post about the most powerful developer tool ever made I had a person leave a comment that said this:
I could not agree with you more. Google is your friend! I actually landed my current job because of Google. In my interview I was asked the question, "How would you rate your skills in C#, 1-5?" I replied "4", even though I had never seen a line of C# code. He asked me why I rated myself a 4 and I told him, "Programming is a skill, once you know how, everything else is just syntax and I can just Google the rest."
This comment had me thinking for a few minutes. Sure, knowledge of your programming language and environment are very important, but overall, is programming a generic skill that easily translates between platforms, languages, and toolsets? My first response was “kinda”, object oriented programming is a generic skill. If you know how to write good object oriented software, then you are likely to be able to easily translate that skill into another, demonstrably similar, language.
Continue reading the rest of this post...