Lets say there are two components that make our simple system – Component A and Component B. Component A depends on Component B. From unit testing perspective, comp B developer has created a robust set of "stub" data to meet his testing needs. Since Component A collaborates with B, the developer who is authoring A wants to leverage the test data already written for B. Now this introduces data dependency because the unique id(s) & data used to drive B is now needed by A. This means 'A' and 'B' developer need to sit and talk about Data before they can author unit test cases. While this model might work when things are simple, some of us are asking questions like – will it scale? etc

That's said, if you could provide your thoughts, opinions, help for the following questions, it would help us move in the right direction

What is your opinion on using stub data for Unit Testing?
Is this the way to go or are there other better ways?
Does the stub based approach scale well when there are many components, developers etc (including offshore)
Is this just too brittle where the maintenance of test cases/data could become a chore?
Will this just introduce "communication & coordination" complexities?
Should we think about a interaction-based testing (mocks) instead of state-based testing (stub)
If so, any pit falls with this approach

So far there are lot of unit testing frameworks available today to choose from. Each stands with different approach.
But the matter of fact is, we still need to code. Can we not configure beans what we want to test and actual and expected results?

Imagine a world where we write unit tests, if it's not so complex, in xml instead of creating lot of classes.

So here is an idea for a framework where you write your unit test cases in xml and not create any classes.
The framework provides a helpers/wrappers around various unit frameworks like Junit, TestNG, Jmock etc.
It reads the definition of test case and data providers and generates TestCase using any of above specified Unit Testing frameworks and executes it. We can even set-up some callback mechanism for better control over automated behavior.

Your thoughts.

We might also be getting usage examples in the future in a separate article.

Thank you for your time.

public void testActiveWhenCollaboratorIsActive() {
// Normally done in setUp
SimpleService service = new SimpleService();
Mock collaborator = mock(Collaborator.class);
service.setCollaborator((Collaborator) collaborator.proxy());

// Actual test
collaborator.expects(once()).method("isActive").will(returnValue(true));
assertTrue(service.isActive());
}

I tend to prefer dynamic mocks simply because when doing TDD you don't always know the full API of the collaborator. If you are using stubs, this results in the horrible situation of having to go through unrelated tests and adding/removing/changing methods every time you change the API of a collaborator (add a new method etc.).

This isn't a problem with mocks because you only describe the bits that you are using…if a new method is added to the collaborator, who cares

Mocks also (IMO) lead to much more readable code as well, they also allow you to define the behaviour of multiple calls to the same method. Of course this can be done using stubs, but the code is much more complex.

Nice article.