Archive
Partial Mocks
Blogmark: Behavior Driven Development (BDD)
Blogmark: TDD links collection
Some Test Driven Development observations (A nice roadmap)
Pasted from <http://blog.jayfields.com/2006/06/some-test-driven-development.html>
Blogmark: Unit Testing Private Methods
Testing Private Methods with JUnit and SuiteRunner
Inserted from <http://www.artima.com/suiterunner/privateP.html>
Testing private methods (Bruce Eckel’s blog)
Pasted from <http://onthethought.blogspot.com/2004/11/testing-private-methods.html>
Testing private methods (TestDriven JUnit Forums discussion)
Pasted from <http://www.testdriven.com/modules/newbb/viewtopic.php?viewmode=thread&order=ASC&topic_id=427&forum=7>
Inversion of Control, Dependency Inversion Principle and Dependency Injection
Inaroozhthum naara malaranaiyar katrathu
unara virithu urayaathaar – Valluvar
Meaning: One is like a flower which doesn’t have fragrance if (s)he cannot explain in detail what (s)he has read.
This is exactly how I was feeling in the last couple of discussions we had on Inversion of Control(IoC).
Here’s an attempt.
A program is in control, a program calls a library.
A framework is in control, A framework calls a program.
This is called Inversion of Control (other words Hollywood Principle, Don’t call us we’ll call you)
Why should the framework call you? We’ll just step a few years back in history when people were programming against the Win32 API.
Then
#include <windows.h>
const char *ClsName = "BasicApp";
const char *WndName = "A Simple Window";
LRESULT CALLBACK WndProcedure(HWND hWnd, UINT uMsg,
WPARAM wParam, LPARAM lParam);
INT WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPSTR lpCmdLine, int nCmdShow)
{
MSG Msg;
HWND hWnd;
WNDCLASSEX WndClsEx;
// Create the application window
WndClsEx.cbSize = sizeof(WNDCLASSEX);
WndClsEx.style = CS_HREDRAW | CS_VREDRAW;
WndClsEx.lpfnWndProc = WndProcedure;
WndClsEx.cbClsExtra = 0;
WndClsEx.cbWndExtra = 0;
WndClsEx.hIcon = LoadIcon(NULL, IDI_APPLICATION);
WndClsEx.hCursor = LoadCursor(NULL, IDC_ARROW);
WndClsEx.hbrBackground = (HBRUSH)GetStockObject(WHITE_BRUSH);
WndClsEx.lpszMenuName = NULL;
WndClsEx.lpszClassName = ClsName;
WndClsEx.hInstance = hInstance;
WndClsEx.hIconSm = LoadIcon(NULL, IDI_APPLICATION);
// Register the application
RegisterClassEx(&WndClsEx);
// Create the window object
hWnd = CreateWindow(ClsName,
WndName,
WS_OVERLAPPEDWINDOW,
CW_USEDEFAULT,
CW_USEDEFAULT,
CW_USEDEFAULT,
CW_USEDEFAULT,
NULL,
NULL,
hInstance,
NULL);
// Find out if the window was created
if( !hWnd ) // If the window was not created,
return 0; // stop the application
// Display the window to the user
ShowWindow(hWnd, SW_SHOWNORMAL);
UpdateWindow(hWnd);
// Decode and treat the messages
// as long as the application is running
while( GetMessage(&Msg, NULL, 0, 0) )
{
TranslateMessage(&Msg);
DispatchMessage(&Msg);
}
return Msg.wParam;
}
LRESULT CALLBACK WndProcedure(HWND hWnd, UINT Msg,
WPARAM wParam, LPARAM lParam)
{
switch(Msg)
{
// If the user wants to close the application
case WM_DESTROY:
// then close it
PostQuitMessage(WM_QUIT);
break;
default:
// Process the left-over messages
return DefWindowProc(hWnd, Msg, wParam, lParam);
}
// If something was not done, let it go
return 0;
}
Almost every program written then used to have these code in addition to the application code. So a Framework can have this code built in and we can provide the application specific code which the framework can call. By that way the Framework can have all the plumbing and leave the application only with things which the application is interested in.
Now
using System;
using System.Windows.Forms;
public class BasicApp : Form {
public static void Main(string args[]) {
BasicApp form = new BasicApp();
Application.Run(form);
}
public BasicApp() {
this.OnLoad += new EventHandler(HandleLoad);
}
public void HandleLoad(object sender, EventArgs e) {
MessageBox.Show("Hello World!");
}
}
Inversion of Control takes reuse to the next level. This code has very less plumbing compared to the Win32 one. The framework calls you (as opposed to you calling the Win32 API) using the delegate.
How can frameworks call your code?
The problem in Framework calling your code is that the Framework does not and cannot know that your code exists. So How can it depend on you code and call you. Welcome to Depdency Inversion Principle (DIP). Both the framework and your code depdend on a abstraction and the abstraction provides the famework the ability to call you. Rather the the Higher level module (the framework) depdening on the lower level module (your code). Both depend on the abstraction (delegate). What are the possible abstractions that can be used?
The framework can use
Abstract classes (virtual dispatch)
Interfaces
Delegates
Function Pointers
Closures
Special Methods (e.g. Main)
What is Dependency Injection?
When an object is dependent on another object, the dependency can created by the object itself (the object is in control). Or an external framework can instantiate and provide the depedency (typically based on configuration, making your code more pluggable. The framework is in control here). This is called Depdency Injection. This is a specific case of IoC. DI combined with DIP can make you code more pluggable.
Suggested Reading:
Inversion of Control:http://martinfowler.com/bliki/InversionOfControl.html
Dependency Inversion Principle: http://www.objectmentor.com/resources/articles/dip.pdf
Dependency Injection: http://www.martinfowler.com/articles/injection.html
The Delegates Abstraction: http://sendhil.spaces.live.com/blog/cns!30862CF919BD131A!346.entry
Closures: http://www.martinfowler.com/bliki/Closure.html
Iteration Retrospectives
Retrospectives:- We continually improve our work habits.
Pasted from <http://www.jamesshore.com/Agile-Book/retrospectives.html>
Some Patterns for Iteration Retrospectives
Pasted from <http://xp123.com/xplor/xp0509/index.shtml>
How To Run An Iteration Retrospective
Pasted from <http://www.industriallogic.com/papers/HowToRunAnIterationRetrospective.pdf>
The team had been running iteration retrospectives for several months and they had consistently identified the same issues in need of improvement.
Pasted from <http://radio.javaranch.com/lasse/2006/02/13/1139795651169.html>
Retrospective Questions
Pasted from <http://www.futureworksconsulting.com/blog/2007/02/09/retrospective-questions/>
Iteration and Release Retrospectives: The Natural Rhythm for Agile Measurement
Pasted from <http://www.agilejournal.com/content/view/51/>
Retrospectives
Pasted from <http://codebetter.com/blogs/jeremy.miller/archive/2007/05/03/retrospectives.aspx>
Better Agile Retrospectives
Pasted from <http://theagileblog.net/2005/11/better_agile_retrospectives_1.html>
Sendhil's Cyber Home 