Design Tech Talk Series Presents: OO Design for Testability

One of the main challenges in adopting TDD methodologies and automated testing with xUnit frameworks is to create an appropriate OO design that is testable. The following video, presented by Misko Hevery, a Google Employee heavily promoting testability (see Testability Explorer, Writing Testable Code Guide, ...), gives an insight in how you can create a more testable design.

Duration:
56 min

TDD Test == Unit Test or TDD Test <> Unit Test?? Is it Really Important??

Recently I had an interesting buzz conversation with a former work-mate, Peter. Just like myself he heavily orientates his learning to best practices, especially into agile software development methodologies and automated testing.
I was doing a refactoring session, modifying a huge part of the core logic of my Android app which I'm currently writing as a part of my MSc thesis and after succeeding I published the following message on Twitter:

just #refactored application critical core logic. Would have been totally impossible without #unittest

Source: http://www.doolwind.com/blog/

Consequently Peter reacted, asking me about whether I would say that TDD tests are unit tests? His question made me think...actually I never posed a similar one to myself. From a pure theory point of view I'd say "not necessarily" which was also my first answer to him.

Unit tests are supposed to test a single unit in isolation. TDD - which is usually referred to as Test Driven Development although I personally prefer Test Driven Design which in my opinion captures its meaning in a more precise way - tests are not said to necessarily cover a single unit. They are meant to drive your design s.t. it becomes incrementally (like Kent Beck calls it in his Extreme Programming Explained), evolving (evolutionary as by Fowler). So in theory they may also cover multiple units.

Apparently there is much discussion in the community about this difference which I never really noted so far.

Do we really need to be so strict? 

When working on my Android app I proceed in a TDD way. There are days where I don't even touch the emulator but rather I do quick test->implement->test cycles which give me all the feedback I need till then comes the point of integrating everything where I will use the emulator to verify everything and deploy it also on real devices.
I also do write unit tests, taking my unit out of its context, verifying its correctness in isolation. But hey, I never ever worried about whether I was writing "unit" tests or "TDD tests". Sure, some of my TDD tests are pure unit tests and others cover 2-3 units maybe, but I've always seen the unit testing framework as the tool and TDD the methodology. Do we need to be so strict about this difference? Would it change the way we write the tests during development??

What really matters!!

Theory is important for learning. People need to understand the differences and it is clear that we have to highlight and express them. But ultimately what counts when working with automated tests is feedback. Those automated tests are so valuable during development because they give you a feedback, like customers will give you when you show them your app. This motivates and shows you're on the right path during development.
Then there is regression testing. Nobody is perfect and so you always again run into sub-optimal situations during development. But do you have the courage to refactor and make it better? How will you be able to know you didn't break anything else? IMHO serious refactoring cannot be done without a substantial suite of automated tests (your regression testing suite) which has an acceptable code coverage.
TDD is so important because it will definitely improve your design [1], [2] and more importantly it is a test-first approach. As mentioned, code coverage is important for being able to trust your tests. With a test-last approach, first you just won't be able to reach such a high code coverage as in a test-first scenario and secondly writing tests after will result in much more pain and effort.

What you should distinguish is between those tests that have to pass in every imaginable state of your app (usually unit tests) and those which potentially may fail or take a bit longer to succeed (typically integration tests where you access the file system, network resources, DBs...).


[1] D.S. Janzen and H. Saiedian. Does Test-Driven Development Really Improve Software Design Quality? IEEE Software, 25(2):77–83, 2008.
[2] L. Crispin. Driving Software Quality: How Test-Driven Development Impacts Software Quality. IEEE Software, 23(6):70–71, 2006.

HowTo: Teach Visual Studio to Remember Your TFS Password

I often now ran into the problem of continuously getting queried for the TFS credentials when connecting to the company's TFS server from my personal notebook. The reason is clear, the Visual Studio (2008) TFS client is coded in a way that it takes your standard Windows authentication credentials. This is fine, but still I'd like to have at least a "Remember password" functionality somewhere since it may easily be the case where I want to connect to different TFS servers which may reside in different domains, with different credentials.

I was tired about this misbehavior and so I did a deep search on Google. After reading through several blog posts and forums I found that apparently Windows allows you to manually add passwords it should manage.
Here are the steps for setting everything up.

1. Open the Run dialog (Win+R) and enter: "control userpasswords2"
2. On the following dialog click on "Manage Passwords"
   
   
   
3. You should then see the following screen where you click on "Add a Windows credential"
   
   
   
4. Enter your credentials but remember to prefix with "domain\username" if you reside in a different authentication domain.
   
   
   
5. Finally you should see your registered credentials as follows
   
   
   

If you start Visual Studio now you shouldn't see the nerving TFS popup window any more (given you entered the correct credentials before :) ). Hope this helps.

The World of ListView

I just watched Roman Guy's and Adam Powell's (two Android UI framework engineers) talk about the "World of ListView". They gave the presentation on this year's Google I/O event in May.
The talk is quite interesting and gives some explanations of the complexities behind the ListView as well as some performance considerations when you write your own custom adapter implementing the getView(....) method.
If you have already quite a lot of experiences in developing Android apps this is probably not so interesting for you, but still it may be worth scrolling through the slides.

Duration
1h

Do I Really Need to Test This??

Yes! Let's start straight of with an example. Consider I have my service (business) class SourceCodeItemService and an according SourceCodeItemDao class in my nicely layered app and there is the method removeSourceCodeItem(SourceCodeItem) with the following content

public class SourceCodeItemService implements ISourceCodeItemService{
   ...
   private ISourceCodeItemDao sourceCodeItemDao; //this will be injected at runtime

   public void removeSourceCodeItem(SourceCodeItem itemToRemove){
      sourceCodeItemDao.delete(itemToRemove);
   }
   ...
}

Note, the method really only has one line and all the logic it executes is to delegate the command to the underlying data access object class. Many devs, especially "unit testing newbies" would be tempted to not test this method because "it hasn't really logic inside but just delegates". Indeed, to some degree this is true, but note that the SourceCodeItemService class is just in its beginnings.

Remember, a test should not only verify the correctness of the current behavior but also preserve that behavior in case of future changes.

I want to be sure that if other devs modify my remove method, it will still work the way I expected it to do!

Said that, let's take a look on how the actual unit test for such a method would look like. First of all, what do we want to verify? We want to test the logic of the SourceCodeItemService.removeSourceCodeItem(...) in isolation. In a test-first approach, we know that our service class will use a DAO for persisting the delete operation. So as there will be no other planned behavior for the remove method we want to assure that dao is being called correctly, nothing more, nothing less.

public class SourceCodeItemServiceTest{

   //setup stuff etc..

   @Test
   public void testRemoveSourceCodeItem(){
      //the dummy item to be deleted
      SourceCodeItem item = new SourceCodeItem(...);
      verify(mockSourceCodeItemDao).delete(item);

      sourceCodeItemService.removeSourceCodeItem(item);
   }
}

That's it. I'm using Mockito here, a mocking library for Java. The verify call in the middle is a call to the Mockito library which assures the method delete of the DAO is correctly called with the object I'm passing. So there is a further check that the correct object is being given to the DAO. However you could easily also achieve the same behavior without a mocking framework, although I highly suggest you to adopt one which suits your needs.

So to conclude, a question that may arise when you look at this is "how I did verify whether the item has actually been deleted". To be honest, I didn't! But this is not the scope of the unit test of this service class here but rather of a possible (integration) test of the SourceCodeItemDao class :)

Every Developer Needs a Blog!

I just watched an interesting talk from Channel 9 held by Scott Hanselman. His message: "Every developer needs a blog". As you can imagine it is a rather non-technical talk, but still interesting cause he emphasizes the importance of being "socially" active the "geek way" ;)
If you have already a blog or you're an active Twitter or SO user it might be less interesting since you're already on the "right path".

Hanselman wrote an according SO post the day before the talk and a guy answering the post about why social networking might make you a better developer, wrote a very good answer:

But seriously, I think the biggest thing it does is remind people what a good developer can be. If you are someone who enjoys to go for a jog 2-3 times a week, you could very easily be the best runner you know. You might think that what you do is at or near the limit of what anyone could expect to do.

Until you go to a 5k filled with other serious runners. Then you realize where you stand.

Here are the vids:
Video Channel 9 Part I
Video Channel 9 Part II (haven't seen that yet)