September 3, 2006 Uncategorized

Prototype: DX Testability

So I have been holding on to this DXCore plugin for a while now.  I would like to have it a little more polished but it is just a prototype so I guess I should release it.  It adds three new metrics to DXCore; Compound Cyclomatic Complexity, Efferent Coupling, and Compound Efferent Coupling.

Just in case you are not familiar with DXCore’s metrics they will also show to the left or right of the member declaration (see images below).

These metrics are a first crack at giving realtime feedback to developers as to how difficult there design will be to unit test.  These new metrics provide information about the type population that the test subject member depends on.  Efferent Coupling is based of the member not the type, meaning the the starting point for gathering the metric is the member.  In this case what types does Fill depend on, not what types does Fills parent class depend on.  Remember the metrics are geared to provide information on the test subject member not the entire test subject class.  Compound Efferent Coupling gives you the size of the type population that you will be working with in a unit test.  The Compound Cyclomatic Complexity tells you the overall complexity of the type population.  The easier a test subject is to test the lower all these metrics will be.  In the examples below the test subject member is Fill.  Please notice there are two images for each metric, a bad and a good one.  The bad includes a dependency on Warehouse the Good only depends on IWarehouse.

 

Bad Efferent Coupling (5)

Bad Efferent Coupling (5)

 

Good Efferent Coupling (2)

Good Efferent Coupling (2)

 

Bad Compound Efferent Coupling (7)

Bad Compound Efferent Coupling (7)

 

Good Compound Efferent Coupling (3)

Good Compound Efferent Coupling (3)

 

Bad Compound Cyclomatic Complexity (16)

Bad Compound Cyclomatic Complexity (16)

 

Good Compound Cyclomatic Complexity (11)

Good Compound Cyclomatic Complexity (11)

Warning!

This is not production worthy.  It is not optimized, in fact it can be down right slow depending on the code being analyzed.  As well the algorithms that generate the metrics may have bugs.  This is a prototype.  It’s purpose is to help get more information and determine if there is a product in this idea.

Download

 Note: You will need to have DXCore installed.  You can download it from here.

kick it on DotNetKicks.com

5,824 Total Views

2 to “Prototype: DX Testability”

Trackbacks/Pingbacks

  1. Prototype: DX Testability…

    You’ve been kicked (a good thing) – Trackback from DotNetKicks.com…

  2. [...] Many times testability is the only force in the system that puts focus on indirect dependencies.  When I was prototyping DX Testability I diverged from the standard way for computing Efferent Coupling.  I counted indirect dependencies as well as direct.  I knew that indirect dependencies are important to testability yet I had not put together how in most cases they are not a concern in good OOD. [...]

  1. DotNetKicks.com says...

    Prototype: DX Testability…

    You’ve been kicked (a good thing) – Trackback from DotNetKicks.com…

  2. JayFlowers > A Crucial Difference says...

    [...] Many times testability is the only force in the system that puts focus on indirect dependencies.  When I was prototyping DX Testability I diverged from the standard way for computing Efferent Coupling.  I counted indirect dependencies as well as direct.  I knew that indirect dependencies are important to testability yet I had not put together how in most cases they are not a concern in good OOD. [...]

Leave a comment

*

here