Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Purpose

Over the last year or more I've been learning unit testing via books I've read recently like The Art of Unit Testing, Working Effectively with Legacy Code, and others. I've also been using unit tests, mocking frameworks, and the like, periodically at work and definitely see the value.

However, I'm still having a hard time wrapping my mind around TDD (as opposed to TAD) when the situation calls for code that is gong to mostly use external API calls.

Problem to solve

Get the process associated with a windows service using the service name.

example: Function GetProcess(ByVal serviceName As String) As Process

Rules

  • Show each major iteration in production & test code using TDD
    • No need to see any other code or configuration that is required to get things to run. Just curious about the interfaces, concrete classes, and test methods.
  • C# or VB.NET
  • Must use the .Net framework regarding services/processes (i.e. System.Diagnostics.Process)
  • Test Frameworks:
    • Nunit or MSTest
  • Isolation Frameworks:
    • Moq, Rhino Mock, or Microsoft Moles
  • Must write true unit tests (no integration tests)

Additional notes

As far as I can tell there are two approaches design wise.

  1. Use an Inversion of Control approach along with using the Adapter and/or Facade patterns to wrap the underlying .net framework objects dealing with processes and services.
  2. Keep the .net framework code in the class containing the Get Process method and use code detouring (interception) via Microsoft Moles to isolate the hard dependencies from the method under test.
share|improve this question

2 Answers 2

up vote 5 down vote accepted

I am not sure I understand why do you want to do this (apart from dealing with an intellectual challenge). This kind of code, where you work directly with some system level API, is very hard to unit test, TDD style or not, and to be frank, I don't find it very valuable to try it in a real project.

Most of the task you describe is calling the right low level API method with the right parameter. And the rest of the code as is may be so trivial, it wouldn't necessarily warrant the introduction of a dedicated interface, mock objects etc. I would be content having an integration test to verify on a higher level that the whole stuff works. But this is just my 2 cents.

Unit testing for me is not about following rulebooks or strict definitions. In real life, I don't really care whether my tests are "real" unit tests or not; as long as my code is being covered by automated and repeatable tests, I am fine. I prefer the pragmatic approach.

share|improve this answer
    
Yes, that's why I struggle with TDD in this example. However, others feel this type of code should be developed via TDD over on this SO post. People are arguing there is enough logic in this functionality to warrant TDD (even though it seems to me that there is little-to-no logic). –  Matt Feb 10 '11 at 20:17
    
@Matt, the answer you link does not say you should be writing code against system APIs in TDD fashion; on the contrary. "I really think you can't do test-first development against mocks here." That is, you must test the code against the real API with all its quirks, i.e. you must not isolate your code from the system, hence you can't do classic unit tests here. –  Péter Török Feb 10 '11 at 20:29
    
One person agrees with you on that post and I too feel that I'm leaning that way, but I am curious about the other view such as: "Both of your examples have enough logic in them to be worthy of tests; I would test-drive both of them." –  Matt Feb 10 '11 at 20:32
    
@Matt, note that Mark is talking about a very different aspect than what regular TDD is concerned about. His tests are really classic integration tests. You need to have these indeed, and you need your unit tests too, to test any complex enough piece of your code you can test in isolation. –  Péter Török Feb 10 '11 at 20:33
    
@Matt, I tend to agree with Carl in general. Your concrete code examples are a borderline case to me, so I am undecided whether I would unit test them. It all boils down to how much time and resources I have. In a nice clean project where I am writing code from scratch TDD fashion and most of the rest of my codebase is neatly covered already, it would be quite natural to try to cover these methods too. OTOH on a big legacy project where unit test coverage is well below 50%, I would say there are far more important tasks to spend my limited resources on. –  Péter Török Feb 10 '11 at 20:37

There comes a certain level where you can't separate the unit from a system resource. When developing a system using TDD, you are going to keep that amount of code as small and contained as possible. In this case, you might start with a concept called IProcessManager. That concept is nothing more than an interface that will define the GetProcess and other process related methods you need.

interface IProcessManager {
    Process GetProcess(string processName);
}

"Why an interface?", you ask. Because interfaces are easier to mock than global functions. The purpose of mocking the process manager is to ensure all your code that uses this function will behave properly in the different error conditions that can occur. What happens when there is no process by the supplied name? What happens when processName is null? Your mock implementation of IProcessManager can easily recreate these conditions for you.

The other side of the coin, the actual process of implementing the behavior your expecting is now very well defined, and your problem is well contained. You can either write the implementation without tests, or you can at least write tests for the conditions you can predict and control. For example, if you can detect the name of the currently running process at runtime, you can write a test to find that Process by the name. Also, you should be able to come up with an illegal process name and one that will never exist.

Just understand that there will be some parts that simply cannot be tested properly. You can only do what you can to limit the possibility of things going wrong.

share|improve this answer
    
I get the IProcessManager and is what I have in the code I'm playing with. So in your opinion would the implementation of GetProcess be the case where, "there comes a certain level where you can't separate the unit from a system resource?" Example 3 line implimentation: **(1)**ManagementObject managementObject = new ManagementObject(string.Format("Win32_service.Name='{0}'", name)); **(2)**int processID = Convert.ToInt32(managementObject.GetPropertyValue("ProcessID")); **(3)**return Process.GetProcessById(processID); –  Matt Feb 10 '11 at 20:43
    
Pretty much. Other examples include when the system throws an exception only when the platform isn't properly installed (Java has a few of those), or a part of your application opens network sockets for communication. As soon as you start testing those things you'll find that your tests can break for a myriad of reasons (the communications port is already in use, the server side that is listening for the call is down, etc.) –  Berin Loritsch Feb 11 '11 at 2:28

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.