Agile and The Taproot of Trust I have been reading a lot of Steven R. Covey’s works lately and one of my friends is trying to champion Scrum at work. Marinating in these two has started to clarify some nebulous issues with Agile for me. They are not crystal clear, they just aren’t as muddy. Take Steven’s article Taproot of Trust and read the first line: Efforts to empower employees and to align systems will be forever frustrated in cultures of low or no trust. ...
Single Responsibility Principle and Testability Straight from the source: THERE SHOULD NEVER BE MORE THAN ONE REASON FOR A CLASS TO CHANGE. What is a Responsibility? In the context of the Single Responsibility Principle (SRP) we define a responsibility to be “a reason for change.” If you can think of more than one motive for changing a class, then that class has more than one responsibility. This is sometimes hard to see. We are accustomed to thinking of responsibility in groups. ...
The Interface Segregation Principle and Testability So c2.com does not maintain a good page on ISP. I will lean on David Hayden to round up a quick explanation of ISP: The Interface-Segregation Principle focuses on the cohesiveness of interfaces with respect to the clients that use them. Here are some other descriptions I found while Googling: “Many client specific interfaces are better than one general purpose interface“- “The dependency of one class to another one should depend on the smallest possible interface“- “Make fine grained interfaces that are client specific.“- “Clients should not be forced to depend upon interfaces that they don’t use. This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions.“ One of the first things that comes to my mind when exploring how ISP effects testability is surface area. ISP is aimed at reducing how much a client is exposed to, and a test is a client. Reducing surface area can have the affect of reducing the type population as well. This is only really helpful in the context of test doubles (e.g. mock). Using the class behind the slim interface in the test can increase the type population possibly negating all benefit to testability. This constructor to the backing class or it’s implementation can negate the benefit.
OOD Class Principles and Testability This is the final post in my series on OOD class principles and testability. It has included: Single Responsibility Principle and Testability The Interface Segregation Principle and Testability Dependency Inversion Principle and Testability Open Closed Principle and Testability Liskov Substitution Principle and Testability The Law of Demeter and Testability There was a pit stop at YAGNI and Testability as it had some bearing on the OCP. It was all kicked of by Benefits of Testability. Which was inspired by Dr. Stefan Jungmayr’s dissertation Improving testability of object oriented system. ...
Tutorial: Extending MbUnit MbUnit, my favorite xUnit Framework, is easy to extend. This tutorial will cover creating a new type of test fixture attribute and test method attribute. There are basically two reasons for creating extensions: to solve a general need and solve a specific need. The need to create an extension for a specific context happens far more often so we will focus on it. Marc Stober’s comment puts it well “…some of what makes MbUnit popular is that you can use the same framework for integration testing…A lot of us like MbUnit because it just gives us a way to test whatever we think needs testing”. The example I will use in this tutorial will be for an integration test, not a unit test. ...
Testability Questionnaire: Another Response It seems that I misunderstood Kelly Anderson and he wished to be included in the posting. Thanks again for straightening me out Kelly. Here is his reply: How do YAGNI and testability relate? If one subscribes to the point of view that the tests fulfill the role of a live specification, YAGNI is a natural outcome. Writing code to some purpose other than passing the test at hand becomes, with practice, a rather irrelevant exercise. Thus, it doesn’t happen as much as when you are not writing to a live spec. ...
Benefits of Testability I have been having a hard sell of “testability is a good thing” at my work. I feel that unit testing leads to testability leads to good OO. The dynamic mocking application TypeMock.NET has not helped: nor has the article Stop Designing for Testability. TypeMock is a powerful application but I think that it can be misused to allow poor design with ease of unit testing. The pain that unit testing creates when dealing with a low testability test subject is experienced close to when the test subject was created. This gives the developer rapid feedback that there is a design issue. The feedback is experience while the developer is still in flow and can make the needed changes with the lest impact to schedule. So unit testing and testability are like an alarm indicating early that there is a design problem. This sounds like a good thing to me, something that I would not want to circumvent or avoid. There are a lot of other characteristics of design that are related to testability. In particular the list below are benefits to testability. ...
The Law of Demeter and Testability The Law of Demeter, also know as the Principle of Least Knowledge, is important to controlling the type population of a test subject. Here is a fun explain from c2.com: You can play with yourself. You can play with your own toys (but you can’t take them apart), You can play with toys that were given to you. And you can play with toys you’ve made yourself. Explanation in plain English: ...
Custom CCNET Branch - New Features That Could Not Wait! So I have written in previous posts about a project that I am helping automate the build. It is a rather large project, in terms of code, people, and process. We are trying to become more agile but there are some forces that we can not change (eg medical software). CCNET is close to handling all our build needs. It has been lacking some crusal functionality. The ability to create relationships between builds; this is partially implemented. One build can trigger another or watch another. This is good for no traffic regulation situations, small teams. We needed the ability to control when builds could not happen. For example project experimental1 should not be forcible when experimental2 is building or checking modifications: ...
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). ...