Introducing Depender - Testability Problem Finder

Update: Here's how you can extend Depender with your own dependency rules

Depender is a tool that I created to illustrate several concepts both for my book and both for my training classes. I think it should prove valuable (as it gets more and more features) to anyone who is trying to write tests for existing code.

 

Depender allows you to load an assembly and inspect the types within it according to very simple rules. the main question on my mind and I run it is: "How easy would it be to test class X?". Depender will list all the classes in the assembly and for each one will try to detect possible testability problems (non decoupling) and places where you might be able to "inject" your own implementation (calls to virtual methods, fields that are interfaces or types who are not sealed..etc..)

 

so you can:

  • see places where you might want to refactor your code or use a tool like Typemock Isolator
  • see places where you can already use "seams" to inject behavior into your code without needing to look up the source code manually.

here's what the main screen looks like when loading an assembly:

image

the type "RealLogger" is marked in red because it contains calls to static methods. double clicking on the type's node will load a separate window just for this type:

image

 

I will be adding more rules and also releasing the source so that other people can help develop this. for now I just want to get it out there and see what people think.

possible futures:

  • Make it command line driven so it can run in your CI builds
  • Make it give "scores" to assemblies or types on testability and decoupling
  • Make it add "suggestions" on how to fix decoupling issues
  • Make it create the base diagram for my test feasibility matrix

Download Depender from here.

Published Saturday, July 05, 2008 10:08 AM by RoyOsherove

Comments

Saturday, July 05, 2008 11:30 AM by Miki Watts

# re: Introducing Depender - Testability Problem Finder

Looking awesome... I can see it being used when searching for areas to add test coverage to, or teaching new programmers unit tests.

Saturday, July 05, 2008 12:24 PM by ISerializable - Roy Osherove's Blog

# Extending Depender with your own custom dependency rules

In the previous post I introduced Depender , to help find dependency issues in your code (usually for

Saturday, July 05, 2008 12:45 PM by Peli

# re: Introducing Depender - Testability Problem Finder

Silly question: why didn't you implement this as a custom set of FxCop rules?

Saturday, July 05, 2008 1:13 PM by RoyOsherove

# re: Introducing Depender - Testability Problem Finder

Peli: Because I want it to be a simple tool to run, inspect and extend. and FxCop is none of those things.

Saturday, July 05, 2008 2:30 PM by Ayende Rahien

# re: Introducing Depender - Testability Problem Finder

Where did ClrTest.Reflection came from?

Nice.

One thing that it needs is a set of default excludes.

Right now it is reporting errors on static calls to string.Concat and GC.SuppressFinalizers, for insta.ce

Saturday, July 05, 2008 3:00 PM by RoyOsherove

# re: Introducing Depender - Testability Problem Finder

Oren:

The IL Parser is from the methodvisualier I enhanced a while ago

weblogs.asp.net/.../debugger-visualizers-for-methodinfo-dynamicmethod-and-methodbase.aspx

which was written by Haibo Luo:

blogs.msdn.com/.../484861.aspx

with a new version here:

blogs.msdn.com/.../take-two-il-visualizer.aspx

Saturday, July 05, 2008 5:45 PM by Eugenez

# re: Introducing Depender - Testability Problem Finder

Roy,

I also wonder why you did not base it on FxCop.

Why I can buy "not easy to extend" statement regarding FxCop, how's FxCop complicated to run and inspect?

And even with "not easy to extend", there is ready build integration etc. with FxCop.

J

Saturday, July 05, 2008 6:05 PM by RoyOsherove

# re: Introducing Depender - Testability Problem Finder

I have played around with FxCop but I found it hard to use and write against. event test (google fxcopunit)

worst thing: most people don't bother using it at all.

Do you use it?

Does anyone who's reading this comment?

Saturday, July 05, 2008 6:49 PM by Eugenez

# re: Introducing Depender - Testability Problem Finder

Roy,

I am not sure how many people write custom rules for FxCop (my guess is not too many),

Myself, I do use it w/out custom rule and know those who do as well (some may use it as part of VS Team System integrated code analysis). Why I am not as happy as I could be about it, I think it is very good tool if you invest some thought before rolling that out in your company.

What do you use for static code analysis in TypeMock? Don't tell me it is Resharper analysis.

And most people do not use unit testing either (let alone mocking frameworks :), but would you write a new one?

I am not saying FxCop would do better, but it surely has wider range than any new tool.

J

Saturday, July 05, 2008 7:07 PM by Bill

# re: Introducing Depender - Testability Problem Finder

I use FxCop, it is integrated with my CI system.

Btw, Gendarme is much easier to extend with new rules (www.mono-project.com/Gendarme).

Sunday, July 06, 2008 5:59 PM by Useful Links #8 | GrantPalin.com

# Useful Links #8 | GrantPalin.com

Pingback from  Useful Links #8 | GrantPalin.com

Monday, July 07, 2008 1:14 AM by Jan Van Ryswyck

# re: Introducing Depender - Testability Problem Finder

How is this tool different from NDepend?

Monday, July 07, 2008 2:06 AM by Tanmay Dalvi

# re: Introducing Depender - Testability Problem Finder

The tool complains when your assembly depends on another assembly unless I put the assemblies that my assembly depends on (such as log4net) in the depender folder. I guess I could put them in Path as well. Any other way that I am missing?

Monday, July 07, 2008 2:08 AM by RoyOsherove

# re: Introducing Depender - Testability Problem Finder

Tanmay: for now putting them in the path or in the same folder is the workaround.

# Dew Drop - July 7, 2008 | Alvin Ashcraft's Morning Dew

Pingback from  Dew Drop - July 7, 2008 | Alvin Ashcraft's Morning Dew

# andreas-schlapsi.com ?? Detecting Testability Problems

Pingback from  andreas-schlapsi.com ?? Detecting Testability Problems

Tuesday, July 08, 2008 2:02 AM by David M. Kean

# re: Introducing Depender - Testability Problem Finder

Three words - reinventing the wheel...

Tuesday, July 08, 2008 3:08 AM by RoyOsherove

# re: Introducing Depender - Testability Problem Finder

David M. Kean:

Three words: YOu are wrong.

FxCop and others only do rules that are "bad"

Depender will also show you "good" places to inject. it's not just "warnings" but also shows places that you can use already.

I'd love to see something that does the same though!

Friday, July 11, 2008 2:59 PM by Code Monkey Labs

# Weekly Web Nuggets #20

General Kill Your Users Table : Rob Conery isn't afraid to ask the tough questions - do we really need to store users' data? With services like OpenID , where the user has complete control over their data and what they present to a site, it's certainly

Monday, August 04, 2008 3:22 PM by Rik Hemsley

# re: Introducing Depender - Testability Problem Finder

Roy,

Please ignore the negative comments.

The tool looks excellent and I'm looking forward to playing with it.

Rik

Monday, September 01, 2008 9:50 PM by My Dev Kit | Alvin Ashcraft's Morning Dew

# My Dev Kit | Alvin Ashcraft's Morning Dew

Pingback from  My Dev Kit | Alvin Ashcraft's Morning Dew