Two Agile teams start working on Application A, at the same time developing exactly same functionality. Team 1 delivers with a constant velocity…
While searching on the internet about AgileEVP (Agile Earned Value Management) I came across a formula from my high school physics: v=d/t, the Average Velocity formula. I really enjoyed high school math, physics, and its exams: Two trains leave Station A at the same time traveling in the same direction, Train 1 travels with a constant velocity…
Here is the formula that got me started:
High School Physics Average Velocity
The average velocity v of an object moving through a displacement (d) during a time interval (t) is described by the formula: v=d/t
where,
v = Average Velocity
d = displacement
t = time
Exercise 1:
What is the average velocity for a car with a displacement of 120 km in the interval of 3 hours?
V = d/t, where d is 120 km and t is 3 h
Solution:
V = 120 km / 3 h = 40 km/h
Average velocity: 40 km/h (the car average velocity is 40 kilometers per hour)
So I decided to compare high school physics average velocity with team average velocity as an Agile development concept.
Typical Agile projects use iteration fixed in time, so instead of t, team average velocity uses the number of iterations as the time variable.
Displacement in Agile is measured by means of story points completed.
Velocity, in Agile, team velocity, means the number of story points the team completed in the Iteration.
Agile Team Average Velocity
The average velocity v of a team delivering story points (s) during the iterations interval (i) is described by the formula: v=s/i
where,
v = Average Velocity
s = story points completed i = the number of iterations
Consider sp for Story point unit, it for iteration unit, and sp/it as velocity unit (Story points per iteration)
Exercise 2:
What is the average velocity of a team with a completion of 120 sp in the interval of 3 it?
V = s/i, where s is 120 sp and i is 3 it
Solution:
V= 120 sp / 3 it = 40 sp/it
Average velocity: 40 sp/it (the team average velocity is 40 story points per iteration)
Agile projects extensively rely on the concept of average velocity. Average velocity is very useful for agile team planning activities such as iteration and release planning. For example, my team is about to have an IPM (Iteration Planning Meeting) and we had to decide the number of story points to sign up for the next Iteration. The Average velocity from the last 3 iterations is a good initial value for the team to go about signing up for work for the coming iteration.
Habits are habituated routines of behavior that are repeated regularly, tend to occur subconsciously, without directly thinking consciously about them.
Self-discipline refers to the training that one gives one's self to accomplish a certain task or to adopt a particular pattern of behaviour, even though one would really rather be doing something else. For example, denying oneself of an extravagant pleasure in order to accomplish a more demanding charitable deed. Thus, self-discipline is the assertion of willpower over more base desires, and is usually understood to be a synonym of 'self control'. Self-discipline is to some extent a substitute for motivation, when one uses reason to determine a best course of action that opposes one's desires.
---------------------------------------
Agile is a low ceremony process which, according to the Agile Manifesto, favors individuals and interaction over process and tools. So in agile we try to use the least amount of process to achieve a certain goal; usually the success of the project. The good thing about high process environments is that you don't really have to worry about what to do, you don't even need to grasp the big picture. Just follow the process and the stated rules. Training and ramp-up time are low. Sounds good? In theory it does, however, in reality many cases fall between rules and are therefore not covered by them. Ever talked to a overwhelmed person in a call center because your situation was not in the handbook? Often, I feel that they could help but won't as they are not authorized to make the call. Agile approaches this problem by moving authority from higher up -- the rule writers -- to the individuals actually doing the work. Command and control becomes leadership and cooperation. This autonomy comes with a price; (Self-)Discipline. People in charge need to be able to put trust into those empowered individuals. With discipline comes a certain behavior. That behavior and its outcome builds trust over time. Like in Spiderman when uncle Ben told Peter Parker: 'With power comes responsibility'.
So far so good. This will work great for as long as you stay in the comfort zone. What happens if unexpected events cause chaos and distress? A classical social behavior is that you yearn for something proven and trustworthy. Usually, it is the habit that worked (at least you think) in the past. In no time we forget about our responsibility towards discipline, we are driven consciously or more likely subconsciously by our habits and run with them once more. Worse, this often causes the situation to become even more dire and the vicious cycle is started.
How can this be avoided? In a typical software project, there are three ways that change can be enacted.
A pool of talented employees go out on their own and secretly implement the new process (they know management doesn't like them to step up).
Management orders that a new process is being used. (command and control)
Both of the former combined -- employees and management want to improve together (leadership and collaboration)
The first two options have a very slim change to succeed, albeit the first one is somewhat better off. Usually good people stick to their conviction and let management talk. However, there is only so much pressure they can take. (You can change the company or you can change the company -- get my drift)
As for the management ordered approach, I see two possible outcomes:
A) Management is curious about agile and sees a potential silver bullet in it, so it decides to 'do' agile and then will flip to next silver bullet once the first clouds appear.
B) Management is convinced about agile and therefore would not only mandate, but facilitate the successful roll-out with trainings, on site consultants and other resources. This brings us the last option of the three.
In the third case management and the employees have the same strong believes and are not willing to give up easily. Open communication and cooperation between those two parties allows for frequent adjustments. In case of shifts in fundamental assumptions, it even allows for changes to the underlying core process . Those adjustments, another agile principle, reacting to change over following a plan, make it possible to keep up with a discipline. Also, disciplines are not cast in stone, they are not dogmas. Feel free to adjust a discipline. However, those changes should have a strong cause and be revisited after an agreed period of time to assess their effectiveness. Often a change is only temporary until another problem has been mitigated.
Over time, with continuous repetition, a discipline will be morphed into a habit. Don't expect this to happen quickly, it most likely will take month if not years. Once you have been lucky enough to experience this for real, you will be transformed for life. Suddenly you have a clear vision and understanding you never imagined possible. There is no going back.
It is all about drinking the KoolAid once! That's what turns a discipline into a habit.
While being a TDD--Test Driven Development--coach, I am always asked about testing private methods. I finally decided to write about my experience on testing private methods.
When really doing TDD (i.e. writing the test code before writing the functional code, and then refactoring the code) private methods are guaranteed to be test covered. When driving the functional code design and implementation from the unit test (aka Test Driven Development), no method is created private. Instead, the private methods are extracted—extract method refactoring step--from a public or package level method. The Example 1 below presents a scenario on applying TDD and how the private method is created.
New code development following TDD
Example 1: new code development following TDD
Consider the development example following a TDD sequence for creating methodA and methodB.
On the first sequence, the testMethodA is created for validating the functionality expected of methodA. The methodA is successfully created: All tests including the testMethodA are passing. Then you look for improvements in the code; refactoring.
On the second sequence, the testMethodB is created for validating the functionality expected of methodB. The methodB is successfully created. All tests including the testMethodB are passing. Then you look for improvements in the code; refactoring.
While looking for improvements in the TDD Refactoring step, you recognize that methodA and methodB have a common fragment of code (code duplication). You extract the common code fragment into a private method whose name explains the purpose of the method--methodC. Then methodA and methodB invoke methodC.
In this example testMethodA covers methodA, which invokes private methodC; therefore the private methodC is test covered.
Please keep in mind that this is a simplified example. Your methods and tests should not read like testMethodA / methodA, and testMethodB / methodB. Jeff Patton describes how test cases can describe design in his Test-Driven Development Isn’t Testing paper.
When doing TDD, the private methods emerge from your code. And because you test-drive your development, no functionality is added without a test. So, for code fully developed by following TDD you won’t have to test the private method separately: Private methods are already being tested by previously written tests.
Improving legacy code following Test-Driven Refactoring
Now let’s look into a more realistic example. The majority of the code I have been working on is not new code; therefore I am not doing pure TDD; instead, I am doing Test Driven Refactoring,
Test-Driven Refactoring
Test-Driven Refactoring is an evolutionary approach to improve legacy code which instructs you to have test-proven refactoring intent. Basically, you start by writing a passing test around the code to be improved, and then you refactor the code; improving its internals, yet still passing the test suite.
While doing Test Driven Refactoring, I am trying to perform small refactoring steps and, at times, I find myself attempting to test a private method. This typically happens when I am working on an existing code base with very low test coverage. And the public methods are too complex to write tests for.
Example 2: test driven refactoring for existing low test coverage codebase.
Consider that you want to improve the following code:
public void overstuffedMethodX(){
…
// very complex code
…
// invoke private method methodY()
someString = methodY();
…
}
private String methodY (){
…
}
In the scenario presented in Example 2, the public method does not have corresponding unit tests. And I don’t feel comfortable refactoring code which does not have tests around it. Therefore I will follow Test-Driven Refactoring for improving the code. Below I will explain two different approaches for doing Test-Driven Refactoring for improving the code in Example 2.
Top down Test-Driven Refactoring
First you create tests for the complex public method:
public void testOverstuffedMethodX(){…}
At this point there is test coverage around the overstuffedMethodX() functionality, so you are able to refactor the overstuffedMethodX() code, including refactoring for the private method methodY().
In the top down Test-Driven Refactoring approach, first the unit test for the public method is created, and then its internals (including the private methods) are refactored.
Let’s now look into another approach.
Bottom up Test-Driven Refactoring.
No test for the complex public method is created.
Instead you look for smaller pieces of improvement.
You change the access level for the private method to make it accessible from a unit test.
private String methodY (){}
becomes
String methodY (){} // package level access in Java
Then you write test for methodY()
public void testMethodY (){…}
Then you refactor methodY(), and verify that the improvement works as the testMethodY() test still passes.
In the bottom up Test-Driven Refactoring approach, you first improve the test coverage and the code for the private methods and the internals of the complex overloaded method. By doing so, the code becomes less complex; after that you can start moving up the chain, increasing and broaden the test coverage until you are able to take care of the public method.
When applying the bottom up Test-Driven Refactoring approach for Example 2, the private methodY() is made package level in order to be accessible by its corresponding unit test(consider the package access level for the Java language). Similarly to testMethodY(), other tests are added in a bottom up approach. After increasing the test coverage and improving the code internals, it becomes easier to create testOverstuffedMethodX(), and finally, refactor the overstuffed complex method.
Top down versus Bottom up Test-Driven Refactoring
Even I consider the top down approach to be more purist as it does not change the private methods access level, its implementation is not always straightforward. The public method might be almost “untestable” (e.g., static, dependencies, long, complex) in its current state. For such cases, a bottom-up approach might be more suitable. As I see it today, code refactoring activity is a combination of bottom-up and top-down approaches that enables you to have small proven steps towards a cleaner solution, which still keep the same interface (the external behavior which is verified by the test suite).
Bottom-line, while doing Test Driven Refactoring, I have provisionally added tests for the private methods. In Java, I deliberately remove the private namespace from the method declaration, changing the method access level to package access level. This way, the corresponding test class--located under the same package--can invoke the method and test it.
But I won’t stop the refactoring until I remove the test for the private methods. I have experienced two refactoring sequences which finish without explicit tests for private method.
In the first refactoring sequence, some later refactoring step moves the private method to a different class. Basically, you realize that the method’s functionality is beyond the original class’s purpose; you identify, create the new class, and move the method – which now is public access level.
In the second refactoring sequence, the method access level goes back to being private and you delete the test which was directly invoking it. Because of the increasing test coverage--as a result of the Test Driven Refactoring--new test scenarios are added for the public method which invokes the private method. Once you (perhaps assisted by test coverage and analysis tools) realize the extra test coverage on your private method, you perform my preferred refactoring step--unnecessary code deletion. The test for the private method can be safely deleted as its functionality is being tested by another test method.
Should I add test for private methods?
So, here is my answer to the test private method question: After successfully doing TDD or Test-Driven Refactoring, your code will not have specific tests for the private methods.
If you are developing new code, you are following TDD. You test-drive the development and no functionality is added without a test. Private methods are only created as the result of a refactoring step. And the path of code going through the private method is already being tested by previously written tests. So, after successfully doing TDD, your code will not have specific tests for the private methods.
If you are improving a legacy code, you should be following Test-Driven Refactoring. In this case, you may provisionally add tests for private methods. Gradually, with the increasing test coverage, the tests for the public methods will cover all the paths, including the paths going through the private methods. At this point, you don’t require the tests for private methods anymore. So, after successfully following Test-Driven Refactoring, your code will not have specific tests for the private methods.
Posts
