Unit tests are for functionality, not code!

Shawn has an interesting post where he talks about why 100% unit test coverage should be one of your goals. I agree 100%. I'm not sure why anyone would say that you shouldn't be testing your properties. Don't you want to make sure they work?


The prevailing philosophy in regards to unit testing is writing your tests before your code. In practice, this happens a lot less than it should. Why should we write our unit tests first?

  • Writing your unit tests first makes you design pieces of your software from the clients perspective. After all, you're writing your code to be consumed. The code itself is not important, it's what it does for other code.
  • Unit tests are meant to test functionality, NOT code! That means if you write your unit tests after the fact, you're probably not focusing on the functionality. You might be trying to come up with edge cases that might not even matter to the client. It's harder to come up with good unit tests after the code is written, because you're not necessarily looking at it from the clients perspective, or from the perspective of the required functionality.

There are two valid ways to increase code coverage:

  • Write additional tests - This only makes sense if you forgot to write the test initially. Since you're tests are verifying functionality, why don't you already have a test for this particular piece of functionality? *Remove the untested code - In a perfect world, this is what you would always do. After all, your tests verify that your code has a certain set of functionality. If you have untested code, that code isn't needed. Why keep code you don't need?

Here is the basic process I recommend:

  1. Come up with a rough design in your head
  2. Write unit tests to test a required piece of functionality
  3. Write the code to provide that functionality
  4. Verify that the unit tests pass, fix the code as necessary
  5. Refactor as necessary
  6. Run a code coverage tool, and get as close to 100% as possible using one of the methods I mentioned previously.
  7. Go to #2 and repeat as necessary

Like this post? Please share it!

See a mistake? Edit this post!

What a developer needs from their manager

I've a read a lot of articles talking about what it takes to be a good development manager. There are also articles about what makes a good developer. I thought it would be a good idea to describe what a developer needs from their manager.


A developer abstraction layer - There is so much stuff that goes on in a company, and I really don't need to know it all. For my own curiosity, give me general interesting tidbits, but more isn't necessary.

Leave me alone - If you interrupt me for no reason while I'm getting a lot of work done, I'll obviously get less done. It's not worth interrupting me just to find out what I'm doing. If I'm walking around, that's probably the best time to talk to me.

Buy any training materials that I request - Books are cheap compared to my salary. If I can learn something new that will save time, the investment will have been worth it. The same goes for magazines, software conferences, etc.

Be flexible - When it's time to get some coding done, there are times that I'll be more productive than others. My computer doesn't care if I'm using it at 3AM or 10AM. You shouldn't either.

Trust - If you don't trust me, you're setting me up for failure. Trust your employees first, and take appropriate action if they give you reason not to trust them. If I know you trust me, I can focus on getting my job done.

Keep me happy - A happy developer is a productive developer. Sometimes there are small things you can do that will keep me happy. Buy lunch every once and a while. Tell me to go home early on a Friday. As a bonus, I won't be looking for another place to work if I'm happy.

Guide, but don't over-manage - You have the big picture, so I need your guidance. That doesn't mean that you have to know every detail about what I'm doing. You're not a babysitter, you're a teammate.

Be accessible - If I get need something, please be available. I may need you to pull in the right resources to solve a problem.

Have answers - You're the hub of the wheel. If you don't know what's going on, you're useless to me. You need to be organized and connected.

Be able to prioritize - You have a better idea of what is important for the overall product. That means I need you to prioritize features accordingly. That means I'll always be working on something important.

Tell me what is expected of me - I need to know exactly what is expected of me, and I need to know how you'll determine if I'm completing what is expected. I also need to know how you're going to gauge my performance. When it's time for my review, there should be no surprises.

If you're interested in more information on this topic, I highly recommend you read "First, Break all the Rules - What the world's greatest managers do differently". It's not specific to development managers, but it certainly applies. In that book, they empirically determined the factors that are the most important traits that promote success and happiness:


  1. Do I know what is expected of me at work?
  2. Do I have the materials and equipment I need to do my work right?
  3. At work, do I have the opportunity to do what I do best every day?
  4. In the last seven days, have I received recognition or praise for good work?
  5. Does my supervisor, or someone at work, seem to care about me as a person?
  6. Is there someone at work who encourages my development?
  7. At work, do my opinions seem to count?
  8. Does the mission/purpose of my company make me feel like my work is important?
  9. Are my co-workers committed to doing quality work?
  10. Do I have a best friend at work?
  11. In the last six months, have I talked with someone about my progress?
  12. At work, have I had the opportunities to learn and grow?

That book is one of my favorites, and I highly recommend all managers read it.

Are there any other factors you feel are important? Leave a comment and let me know!

Like this post? Please share it!

See a mistake? Edit this post!

I finally get the point of inversion of control

I think I'm finally starting to understand the Inversion of Control principle (aka Dependency Injection). I had a hard time understanding most examples out there, because they appeared to be solving problems that didn't even seem like real problems to me. For years I've been writing classes, testing them, and hooking them together. In many cases, I was already practicing inversion of control. The benefit I wasn't seeing was the fact that you can separate the modules in your code and the connections between them.


When you really commit yourself to breaking the problem down into manageable pieces, it does create more testable and reusable code. I already knew that, but when you starting using IoC, it really starts to drive that point across. It's similar to the effect that unit testing has. When you start writing unit tests, you try to make your classes more unit testable. When you start using a dependency injection framework, you try to make your classes more open to injection.

So what is a dependency injection framework? It's the glue that holds your pieces together. Without it, your classes would probably be dictating the classes that it depends on. With dependency injection, the application configuration tells the class what modules to use. A dependency injection framework separates the linking from the pieces.

ioc diagrams

In the diagram on the left, it's a typical tightly coupled design. Every class is hooked up directly to another class. This doesn't mean that each class isn't testable, but it's a very rigid design (which isn't necessarily avoidable). In general, the easiest unit testing was in the classes on the edges, since they have a usable surface area.

The diagram on the right is closer to what I've been creating while using a dependency injection framework. In the first pass, I create pieces that contain my business logic. Then, I can use the dependency injection framework to declaratively define how those pieces are wired together.

At this point, I would have a hard time NOT using something like this. While this concept isn't new, the frameworks have recently become very mature. Personally, I'm using Spring.NET and loving it. One of my pet projects for package tracking,( has been rewritten using a modular, test first, dependency injected design philosophy. I was able to reduce the amount of actual code by quite a bit, increase my testing coverage, and decrease the amount of duplicate code.


I'm sold!

Like this post? Please share it!

See a mistake? Edit this post!

Jason Young I'm Jason Young, software engineer. This blog contains my opinions, of which my employer - Microsoft - may not share.

@ytechieGitHubLinkedInStack OverflowPersonal VLOG