So when I posted an innocuous message questioning the value of the tool I had just used, I got an immediate response.  To me, this is the type of gratification that people get (or used to get) from setting their Facebook status.  Or Tweeting.  Social media, from the consumer's perspective - is virtual screaming.  Just without the caps lock key.  It's everyone's way of saying look over here, it's me, I like politics and I love books and I have a cold and does anyone want to grab a drink tonight? What Facebook realizes increasingly (and Twitter, always resistant to changing their innate simplicity, has gave a moment's thought to) is that eventually you have so many contacts, so many friends, so many followers, so many people who follow you that the signal to noise becomes unbearable without some sort of filter.  All of the conversations, statuses, likes, fandoms, retweets, hashtags, and groups eventually just become an incessant buzz, and we stop paying attention to a lot of it.

The immediate response was a result of having all of 14 people paying attention.  Compare that to the 150 people I'm connected to on Facebook.  Or the paltry 80 or so followers I have on Twitter.  My satisfaction with the experience with Google Buzz at that moment was purely a result of it's infancy. But the buzz grew immediately louder.  I then noticed that the buzz had gotten into my GMail inbox.  To a guy who likes the mantra of Inbox: 0, this was distressing.  Part of the deal with Twitter which elevates it appeal over Facebook is that it is a pretty passive social media.  Direct messages infect your inbox, but those are fairly rare.  Simple replies to your tweets or even mentions can just fade to noise.  But now that there was a level of replication between ubiquitous social exchange and my more formal communication in email - Buzz had taken the most invasive and distracting part about Facebook and actively decided to emulate it.

At least Google Wave, while useless for my everyday interactions (though potentially useful elsewhere) lived out on an island that I could blissfully ignore.

I think that Wave, Buzz, and GMail eventually need to work out whether or not they're the same thing or different things.  Facebook is looking to build a "GMail Killer," and so it seems there is some idea out there that people don't like email and would rather live in a world where the overwhelming noise of social media permeates everything.  It's clear that for Google, taking email and putting eyes on the inbox with greater frequency will lead to more exposure to advertisers and inherently, more ad revenue.  But Facebook has ALWAYS had this model and hasn't been able to consistently demonstrate that users will give advertisers the chance through all of the other noise.

It's tempting to say that people will ultimately reject this model and the invisible hand of the market will demonstrate that when the inbox becomes too busy, people will just tune it out.  Google has provided options for getting Buzz out of your inbox.  But given the potential upside, particularly in Google's business model, I'm also unconvinced they won't try to force this particular feature right down their user's throats.

This is an unfortunate discovery.  While there is no inherent equals() or hashCode() in the Javascript language itself (unless I've missed something) that doesn't mean GWT couldn't make one for me.  JavaScriptObject#equals(...) instead calls super.equals().  Which is really Object#equals(...) and that's really just triple-equality (==).  In object oriented programming, this is what is technically referred to as an absolute pain in the ass. It renders JRE emulation of java.util.Set around JSO's almost useless.  And it really highlights something that I've had in my head a while now:

If you can't use GWT-RPC, you use JSON at your own peril.  JavaScriptOverlay types, while nifty in concept are simply not first-class objects in GWT.  They're more akin to a struct or map.

Let's say you have interface Driveable:

public interface Driveable {
 public void accelerate();
 
 public void brake();
 
 public void tuneRadio();
}

Awesome. Now let's say you have class AbstractDriveable:

public abstract class AbstractDriveable implements Driveable {
 public void accelerate() {
 Window.alert("Vroom vroom!");
 }
 public void brake() {
 Window.alert("Screeeeeech!");
 }
}

Totally cool.  And then you love your favorite FM station in ConcreteDriveable:

public class ConcreteDriveable extends AbstractDriveable {
 public void tuneRadio() {
 Window.alert("Rockin' the oldies!");
 }
}

Then we launch into development mode with whatever our application is, and...something explodes.

So we debug, and upon looking at the code that cleverly calls tuneRadio polymorphically - we notice that our debugger drops into a catch block for a NoSuchMethodError.

It appears that GWT seems to lose track of this common idiom - use an interface to define behavior, realize that interface on an abstract class to create default behaviors, and then strategize those behaviors in concrete implementations.

The workaround is simple: redeclare your unrealized interface method in the abstract class. But this is a pretty nasty little bug. The GWT guys know this, but it's rather critical to GWT that it follow the practices of Java as best as possible. Otherwise it's YAL.

But some of the weary techies I've worked with (particularly middle-management types, for some reason) go off the deep end.  I like to say that when you encounter a technical challenge - there's likely someone else who has also needed to solve a similar problem.  In the instances where that isn't the case - you're in a pretty good position to gain something from solving it yourself.  But truth be told, there are very few large problems out there that people aren't solving.  And yet IT organizations continue to re-invent the wheel - even when economics and time tell them that they should look for an off-the-shelf solution.  This only leaves one real driver for making the build decision when the buy decision is so apparent: politics.  And often it's the politics of the grudge.

I firmly believe that every shop I've walked into that has rolled their own MVC framework, or RIA framework, or rules framework contains an individual who truly believes that the cost of supporting, maintaining, and continuously developing that software is still less than the cost of taking a turnkey solution - either one that is commercial or open source.  I recently had a manager tell me that there was an increasing drive through the IT management structure that the enterprise should own the source and rights to all of the systems that it supports.  This was a crazy notion - are their boundaries to this doctrine?  Will we be writing our own application servers?  RDBMS?  Messaging systems?  Where does this cult draw the line?  And with a little more digging, and without much surprise - I found that this manager had spearheaded a campaign to adopt a particular Javascript framework for client development that ultimately failed and cost the company several millions of dollars.  His dogma seemed crazy, and it was. But it was completely motivated out of fear that technology selection, no matter where the accountability lay - was an avoidable cost of enterprise IT, even if it meant adopting the more extensive cost of building all solutions from the ground up whenever the need arose.

I guess the moral of the story is really that as an IT manager, it's important to recognize the power of the crowd (the community if you will) and the value it can add at virtually no cost to your organization.  That it's important to understand why a 3rd party tool has been selected.  That it's general limitations are known early on.  That your organization is prepared to adopt the tool as if it were it's very own.  This means hiring experts who have used those technologies.  And above and beyond anything else, that when you fail - the goal must be to marginalize the cost of that failure.  You can hedge your bets, you can reduce risk.  But when the dust settles and a selected technology has failed the organization - be sure to take a good hard look in the mirror and be open about where the selection process has failed.

Sometimes it is the captain, and not the ship.

A bland RPC implementation that was based on past work I've done was barfing all over me at GWT compile-time today:

Rebinding com.ryannorris.staffing.client.project.ProjectCreatorService

Invoking com.google.gwt.dev.javac.StandardGeneratorContext@9b32fe

Generating client proxy for remote service interface 'com.ryannorris.staffing.client.project.ProjectCreatorService'

[ERROR] com.ryannorris.staffing.client.Action<T> has no available instantiable subtypes. (reached via com.ryannorris.staffing.client.Action<T>)

[ERROR]    subtype com.ryannorris.staffing.client.Action<T> is not instantiable

[ERROR]    subtype com.ryannorris.staffing.client.project.ProjectCreatorAction is not assignable to 'com.google.gwt.user.client.rpc.IsSerializable' or 'java.io.Serializable' nor does it have a custom field serializer (reached via com.ryannorris.staffing.client.Action<T>)

[ERROR] com.ryannorris.staffing.client.project.ProjectCreatorAction is not assignable to 'com.google.gwt.user.client.rpc.IsSerializable' or 'java.io.Serializable' nor does it have a custom field serializer (reached via com.ryannorris.staffing.client.Action<T>)

I can't say I ever had the pleasure of dealing with this bit of attention to detail from the GWT Compiler in the past.  And while I will readily admit I haven't read every change to the underlying architecture that comes with 2.0, this would seem to be a piece that might be worthy of some special mention.

It is, of course, nearly common sense to make sure that your RPC objects can go across the wire in the proper way, and thus simply respecting the semantics of java.io.Serializable the same way we would in EJB per se, is pretty reasonable.  Just a little more heads up would have been nice.

Update 1: There seems to be some mention of fixing compiler feedback around RPC serialization here.  But this defect doesn't suggest changes that might have actually altered behavior or requirements of the compiler since 1.7.

To get started, let's break down our validation needs along the standard lines that we see in frameworks today.  Widgets need to be able to be Validatable.  That is to say, Widgets must be able to be externally seen as having the capability to execute logic which validates their current state.  In my approach, I've chosen to strategize my widgets rather than visit them in order to validate their data.  This decision is largely to enforce contract-driven development and ensure a high level of testability.

Validatable

package com.ryannorris.gwt.validation.client;
 
public interface Validatable {
	/**
	 * Execute validation on the implementing component
	 *
	 * @return true if validation succeeded, false if validation failed
	 */
	public boolean validate();
}

We also now need an interface that will provide the rules for how validation logic should occur.  Something that is Validatable should be able to validate itself with multiple sets of rules.  Our Validator interface gives us this flexible cardinality, and has a familiar ring to it.

Validator

package com.ryannorris.gwt.validation.client;
 
public interface Validator {
	/**
	 * Execute the implemented validation logic
	 *
	 * @return true if validation succeeded, false otherwise
	 */
	public boolean validate();
}

Yes, these two interfaces are the same besides their name. They are both command interfaces, allowing us to abstract logic behind a single method that we can cope with polymorphically. The idea remember is that Validatable components can re-use many different Validator implementations.

So let's write a simple Validator and Validatable interface.  In this case, we'll be validating date input.

DateFormatValidator

package com.ryannorris.gwt.validation.client.validator;
 
import com.google.gwt.i18n.client.DateTimeFormat;
import com.google.gwt.user.client.ui.HasValue;
import com.ryannorris.gwt.validation.client.Validator;
 
public class DateFormatValidator implements Validator {
 
	private HasValue<String> _value;
	private DateTimeFormat _format;
 
	/**
	 * Create a validator that will verify that the given string is compliant
	 * with the pattern
	 *
	 * @param format
	 *            The format to validate against, per the specification in
	 *            {@link DateTimeFormat}
	 * @param value
	 *            The value to validate
	 */
	public DateFormatValidator(String pattern, HasValue<String> value) {
		_format = DateTimeFormat.getFormat(pattern);
	}
 
	/**
	 * Set the value to be validated
	 *
	 * @param value a string, nominally representing a date
	 */
	public void setValue(HasValue<String> value) {
		_value = value;
	}
 
	/*
	 * (non-Javadoc)
	 *
	 * @see com.ryannorris.gwt.validation.client.Validator#validate()
	 */
	@Override
	public boolean validate() {
		try {
			_format.parse(_value.getValue());
		} catch (IllegalArgumentException e) {
			// the value couldn't be parsed by the pattern, return false
			return false;
		}
 
		return true;
	}
}

So, now I have a Validator. How do I now make a widget, let's say a simple TextBox, Validatable?

Harkon back earlier when I said I was chosing to strategize my Widgets.  That's only partially true.  Because we're aiming for good TDD, and hence we want to rely on dependency injection - we will in fact be decorating them as well.  We will strategize around their ability to be validated, while we will decorate them with the Validators that interest us.  This is important, as we wouldn't want to have 20 different TextBox implementations that handle various Validation permutations.  We would rather one, decoratable TextBox that can be managed by the presenter in our MVP implementation.  So what does our initial stab at a ValidatableTextBox look like?

ValidatableTextBox

package com.ryannorris.gwt.validation.client.widget;
 
import com.google.gwt.user.client.ui.TextBox;
import com.ryannorris.gwt.validation.client.Validatable;
import com.ryannorris.gwt.validation.client.validator.DateFormatValidator;
 
public class ValidatableTextBox extends TextBox implements Validatable {
 
	@Override
	public boolean validate() {
		DateFormatValidator validator = new DateFormatValidator("mm/DD/yyyy",
				getText());
		return validator.validate();
	}
}

Wait, you say.  This isn't at all what you just described!  This is a text box that will only execute one validator for one date pattern! Well, you're right.  We need to find a way to enable decoration of our TextBox in a way that can be nicely tested and extensible.  GWT makes extensive use of decorator pattern, and really strives for testability.  We see this in the various Has interfaces, which are added to classes to give them additional behaviors (such as HasText or HasClickHandler).  So, we will follow suit and create our decorator interface HasValidators.

HasValidators

public interface HasValidators {
	/**
	 * Add a validator to the decorated component
	 *
	 * @param validator The validator to be added
	 */
	public void addValidator(Validator validator);
}

And now our updated ValidatableTextBox.

package com.ryannorris.gwt.validation.client.widget;
 
import java.util.Set;
 
import com.google.gwt.user.client.ui.TextBox;
import com.ryannorris.gwt.validation.client.HasValidators;
import com.ryannorris.gwt.validation.client.Validatable;
import com.ryannorris.gwt.validation.client.Validator;
 
public class ValidatableTextBox extends TextBox implements Validatable, HasValidators {
 
	private Set _validators;
 
	@Override
	public void addValidator(Validator validator) {
		_validators.add(validator);
	}
 
	@Override
	public boolean validate() {
		boolean valid = true;
 
		for(Validator validator : _validators) {
			if(! validator.validate()) {
				valid = false;
			}
		}
 
		return valid;
	}
}

So, that's pretty sweet. I have a collection of Validators as a member of the component - in fact I have a set of them as to ensure no Validator exists more than once on the component.  My validate method now loops through the set of validators and maintains the local state of the validation, allowing the entire validation to fail if any one Validator fails.

A highly testable passive view implementation with this component may look something like:

MySampleValidatableView

/**
 * 
 */
package com.ryannorris.gwt.validation.client;
 
import com.google.gwt.event.dom.client.HasKeyPressHandlers;
import com.google.gwt.user.client.ui.HasValue;
 
/**
 * @author ryan
 * 
 */
public interface MySampleValidatableView {
	/**
	 * Get the {@link HasValidators} behavior of the date box.
	 * 
	 * @return a {@link HasValidators} behavior
	 */
	public HasValidators getDateValidators();
 
	/**
	 * Get the {@link Validatable} behavior of the date box.
	 * 
	 * @return a {@link Validatable} behavior
	 */
	public Validatable getDateValidatable();
 
	/**
	 * Return the {@link HasValue} behavior of the date box. This allows us to
	 * access the value of the control.
	 * 
	 * @return a {@link HasValue} behavior
	 */
	public HasValue<String> getDate();
 
	/**
	 * Return the {@link HasKeyPressHandlers} behavior of the date box. When the
	 * user types a key in the field, we will use this event to validate the
	 * current value;
	 * 
	 * @return
	 */
	public HasKeyPressHandlers getDateKeyUp();
 
	/**
	 * Toggle the visual state of the date box so the user receives feedback
	 * when their date is valid
	 * 
	 * @param valid
	 *            Whether or not the control should reflect a valid date entry
	 *            (true) or an invalid one (false)
	 */
	public void toggleValidDateBox(boolean valid);
 
}

A lot going on here, and it's seems verbose - but it's not, it's just highly testable! We need to be able to access the various behaviors of our text box so that we can test how our presenter collaborates with these behaviors.  We also need to be able to push the passive display functionality back to our view implementation so that our unit tests don't inadvertently require a hosted environment to run.  So our presenter needs to be built to:

1. Create a DateFormatValidator with the appropriate pattern and a reference to the component holding the text value to validate;
2. Decorate the component in the view through the HasValidators behavior;
3. Execute validation whenever the user changes the value of the widget through the HasKeyPressHandlers interface;
4. Alter the visual display of the component by calling the toggleValidDateBox method.

So last but not least, our presenter:

MySamplePresenter

package com.ryannorris.gwt.validation.client;
 
import com.google.gwt.event.dom.client.KeyPressEvent;
import com.google.gwt.event.dom.client.KeyPressHandler;
import com.ryannorris.gwt.validation.client.validator.DateFormatValidator;
 
public class MySamplePresenter {
 
	public MySamplePresenter(final MySampleValidatableView view) {
 
		DateFormatValidator validator = new DateFormatValidator("mm/DD/yyyy",
				view.getDate());
		view.getDateValidators().addValidator(validator);
 
		view.getDateKeyUp().addKeyPressHandler(new KeyPressHandler() {
 
			@Override
			public void onKeyPress(KeyPressEvent event) {
				view.toggleValidDateBox(view.getDateValidatable().validate());
			}
		});
	}
}

So there you have it - a highly testable base for validation in a GWT application using MVP.

In my next post, I'll add an event framework to validation, allowing asynchronous validation and abstraction between overall error handling and validation.

For my part, there's only so much patience I have taking on the burden of supporting multiple browsers and dealing with performance issues.  Particularly if I'm Agile, and I'm focusing on delivering so much value so quickly, it's very hard to explain to a client that the underlying technology creates significant overhead that adds drag to the project.  This is an even tougher sell - particularly when you're open with your client, when alternatives that meet the non-functional needs exist.

For your standard web applications that aren't as client-centric as today's RIA applications, it's certainly true that you are barking up the wrong tree with GWT.  Rails, Grails, and Zend can all give you the non-enterprise delivery tools that accelerate development from the server-side and leave the Javascript problem to be solved in a less holistic, more tactical way.

But it's hard to argue now that anything short of the compilation semantics of GWT is useful in the RIA realm (without the need for a intermediate runtime, of course.)  Javascript is too costly and too brittle in large-scale applications to be subject to human hands.  If you've hired a contractor to build you a web-based RIA and they're not using GWT - it's well worth your wallet to ask them why.

What Perl, PHP, Python, and Ruby have done for application development, particularly classic web application development, has been nothing short of revolutionary.  Take C out of the picture.  Facade it with modern concepts that young developers can take to quickly and get results with.  Lose all accountability for memory management.  Push the heavy lifting to the open source teams maintaining these languages, let them deal with security concerns.

But in the last few years, web applications have changed.  The focus has shifted to moving state management and logic to the browser.  Rich internet applications aim to deliver experiences and tools that simply can't be solved by these scripting languages or even their more heavy-handed older siblings, J2EE and ASP.Net.  Javascript is the new soup du jour.  A slew of abstractions have grown up around the limited facilities of Javascript, all trying to simplify this new mode of development through quirky but innovative approaches to DOM management, component reuse, and RPC.  But all of them are still Javascript.  All of them still take the code written by the engineer and with limited optimization execute it with the browser runtime.  As the complexity of these applications has scaled, the task of making them scalable and performant has become sisyphean.  Web developers have always needed to deal with issues of cross-browser compatibility, interactions with different operating systems, etc.  But now more and more we are talking about the limited capabilities of the browser itself and how it doesn't manage memory in our Javascript applications the way that we are magically accustomed to.  For all the RIA frameworks we have today - Flash, Silverlight, JavaFX, etc., there's still only one platform we can count on to deliver client-centric browser applications, and that's Javascript.

So when the cost of delivering these solutions begins to increase incongruently with the complexity of the functionality we are looking to deliver, what are we to do?

An interesting thing happened the other day in the mobile application space.  iPhone development - typically the domain of pompous Mac owners like myself and a few willing Webkit jockeys, suddenly opened it's doors to Adobe's Flash platform.  After months - no, years of wrangling - Adobe has finally found a way to play on Apple's lucrative mobile platform.  But this isn't Keith Peters' Flash.  This is Actionscript being compiled magically into native iPhone runtime applications.  It's a stunning development, one drawing ire and concern about performance.  But it's not the first time that a development platform hailed for it's scalability and ease of entry now has been used to usurp a underlying native platform which has proven to be a barrier in and of itself into development for the target platform.

Google Web Toolkit started the latest generation of application development, with it's seeds in Microsoft .Net's CLR.

As I noted, Javascript development today is hard.  It requires a significant amount of skill and experience to do right, and there's simply not enough talent around to deliver the types of applications that every web site should be delivering.  There are fantastic software platforms written in C - but as we saw in the initial explosion of web applications, C is not a language that lends itself well to a pool of experienced and cheap labor.  PHP was that language.  Perl was that language.  It distilled down the concepts an engineer needed to know about to deliver a reliable application and simplified those concepts - memory management, semaphores, I/O, etc.  It allowed engineers to focus on solving the business problems of the dot-com boom and subsequent flurries of enterprise IT demands.  Now that the nature of those problems have changed - PHP as a tool is simply a square peg for a round hole.  And given the dreadful performance of our target operating environment, an interpreted language on top of Javascript is not an option.  What is an option is another language platform that could be compiled into JavaScript, complete with optimizations for memory management and portability.  GWT made Java the potential language of choice when it came to RIA development in Javascript.  It once again gave power back to engineers to be able to focus less on the non-functional needs of the application and put the focus back on fulfilling the functional requirements.

While the performance of GWT is stunning and it's architecture a stark deja vu of past optimizations approaches to software compilation - our other example may not quite have the grit.  Compiling ActionScript to Objective-C is a nice trick, but may only solve the problem of heterogeneous development environments for Flash developers who haven't had the guts yet to get into Cocoa development.  Natively, Objective-C is rather optimized, with device performance on the iPhone of platform applications running remarkably well.  So the compiler optimizations that web applications gain from GWT development aren't really there.

But guns are certainly drawn on the problems of complex platform development, whether it be the arcane and aging Javascript platform in the modern web browser or the stifled promise of mobile application development.  For years, the complexity of executing a piece of software on a mainframe (or older system) acted as a significant barrier to delivery of commercial software.  The innovation of the compiler changed all of that.  Fast-forward 50 years later and we see the same problem, and the same solution is staring right at us.  The odd natural selection of software languages will repeat itself it seems.  Once again, the compiler saves the day.

Engineers write code.  QA tests that code.  In the past, this baton model has been derived from extensive functional specifications and use case documents that break down the core, extension, and exception cases so that both the tests and software can be clearly defined.  In a waterfall model, this was functional as it mirrored the sequence of SDLC.  But SCRUM and most Agile processes really shun this kind of thinking and instead target flat teams that collectively own the deliverable.  As in a recent experience of mine, maintaining that same handoff creates all sorts of problems.  Acceptance and rejection of delivered stories occurs late in the game, QA is always in a rush to execute their tests, and product teams and development see QA as a bottleneck.  It's tempting for management to look at this and begin to turn SCRUM into a series of miniature waterfalls.  But this is wrong. Instead, as with all things in SCRUM, the search for a solution needs to answer a few questions to make the possible actions palatable:

1. Will the solution eliminate dependencies my team has?
2. Does this solution change the value that one set of skills adds to my team, or does it distribute it?
3. Will this solution be responsive to change?
4. Will this solution require extensive infrastructure to implement?

Heroes Kent Beck and Martin Fowler will tell you that the best solution is to strive for full, automated testing.  I couldn't agree more.  Manual testing, as Fowler recently said, should be considered "a human rights violation."  It's error prone, difficult to repeat, and handles regression poorly.  That said, there are some battles simply not worth fighting.  In larger, more established teams - this type of shift is glacial, largely because of the risk incurred by such a change in paradigm.  Pragmatism dictates that the value of your QA team be repurposed to continue to add value, though potentially in a different way.

If we can concede the anecdotal thought that most engineers are substandard at QA, then we can see a glaring gap on a SCRUM team.  Even full automated testing with xUnits and CI is going to relinquish some level of code coverage, particularly in legacy software that wasn't designed to be tested 10 years ago.  It should be mandated in teams in this type of pickle that all future code adopt the best practices of TDD - even to the extent that older, less TDD-friendly technologies and architectures be phased out.  But as we engage a group of engineers in a methodology in which they may never have been educated, hired, or trained for - on the sidelines we have a group of people who have been identifying failure and success scenarios their entire careers - even if they aren't engineers.  A QA team can be indispensible in this situation.

In your new, SCRUM-based project - QA no longer are the gatekeepers.  We can't have multiple gatekeepers in SCRUM.  Instead we focus on delivery and acceptance, creating one gatekeeper - a single keeper of the truth: the product owner.  That role is intended to be their exclusive domain.  They are the most intimate with the domain, the most intimate with the user story, and the most knowledgeable of where value lies.  To vest these judgmental by proxy in a serial part of the development cycle only leads to confusion.  Who is really assessing value?  Who is ultimately going to decide whether or not a story can be delivered?  Who should decide whether it should be accepted?  The demographics of a SCRUM project exist to solve this very question.  Eroding the clarity of role simply detracts value.

So what does this mean?  QA can't be relegated to the role of testing system.  They cannot be an analogue for some sort of software framework.  Our goal should be to migrate to full automation, even if that takes time.  This means that the role of QA changes to an engineering role.  Not in the software sense, but in developing the cases which need to be tested.  These will arise from:

1. Conversational contributions to the story, noting and documenting constraints by guiding the product owner through different user experiences.  These can come out of user flows or non-functional prototypes.  But QA can add extensive value simply by contributing their ability to identify edge and corner cases that may not have been considered.  These may well not end up in our confirmation of the story, and it's important for QA to recognize, just like with an engineer - that the value of a contribution in the conversation is to help shape the conversation, and not set requirements in the stead of the product owner.
2. Test cases derived from the constraints outlined in the conversation.  Take this user story:

   A user must be able to provide a credit card for payment of their order.  Each credit card must be validated with the issuer, and we will only accept credit cards from Visa and MasterCard.

   Try it with Discover card.
   Try it with American Express.
   Try it with an invalid billing address.

   This is the way that the product owner will ultimately accept the story.  The QA resource working on this story may write several test cases that test the edge and corner cases of the acceptance criteria, but they need to maintain an open conversation with the team to ensure they aren't incidentally increasing scope by applying tests that go outside of the criteria.  So while the following test case is very likely to be something we'll want to test:

   Try a billing address where the street name is provided in all capital letters but matches the address on file which is entirely in lower case.  This is expected to be a positive case, with the validation succeeding.

   This test would likely be considered an expansion of scope or otherwise invalid:

   Try charging the card and ensure that we put a $5 hold on the card until the transaction is complete.

So, in the cycle of the development of the story, the test cases serve as the outline for the engineer - as they should.  The engineer uses the tests to validate their code - or more effectively, runs their code against an automated test that implements the test case as defined by the QA specialist.  This helps improve quality and minimize risk by taking those decisions which we earlier agreed that engineers are poor at, out of their hands.  The test cases serve now as the same direction that the rest of the story does.  For those tests which remain manual for whatever reason, the effort to complete those tests can now be load balanced across the team, rather than vested in the hands of one point of failure in delivery.

Ultimately, this is what is so enjoyable about an Agile project.  Because it suggests solutions through it's objectives, it's possible to solve any execution concern by referring back to the principles that make Agile delivery successful.  Being able to respond to change, emphasize people and interactions, and prefer generalization over specialization is the guidance we can use to look at the role of the heroic QA team in a different light - a somewhat specialized engineering team that delivers artifacts that infuse delivery with the value that it may not be realizing in engineering, and not acting as a secondary source of truth for the team.

So understanding how a unit test is traceable back to a technical design on an agile team is really a key differentiation between an approach that more closely resembles cowboy coding and an approach which is relatively holistic.  No scrum master, project manager, or even architect would advocate full designs in an agile environment - instead we opt for lighter weight approaches to technical design that provide a blueprint to the code.  For many teams, this is a CRC card - a simply way of documenting the various dimensions of an object-oriented unit.

What is a CRC, and how does it relate back to tests?

Class

The core unit of code that we will refer to is the class, but this can be really any aggregation - a function library even.  This represents a loose collection of related functionality that leverages common resources, represents a concept of actions or identity, or extends existing functionality.

Responsibilities

The responsibilities of the class form it's raison d'etre. Commonly, we can analogize responsibilities with methods, but they may be more coarse grained - and our refactoring may indeed refine the level of detail with which we understand the functional responsibilities of the class.

Collaborators

From an interestingness perspective, particularly in the context of unit testing and mocking (or stubbing), collaborators really take the cake.  When we talk about dependency injection as the core pattern of test-driven development with mocks, collaborators are indeed what we are injecting into our class to power it.

I always ask my green developers to think about these things before starting any sort of development.  Once their CRC is done and we agree on the approach, I ask them to build the programming interface, stub the implementation, and then start writing tests.  A common example I like to use when I get that befuddled look is the idea of a car.  A car has a lot of complex stuff going on that if I needed to test dependent functions of the car against, I wouldn't want to have to concoct all of the function they provide.  For instance, the engine is a complex piece of machinery - but if I solely want to to test how my transmission reacts to engine behavior - it's the transmission class I want to ultimately test, and it's reactions to different engine behavior.

Let's bring it up a level and talk about a Car as the core class.  We want our car to be able to do two things - to have two responsibilities: accelerate and stop.

public interface Car {
   int accelerate(int additionalVelocity);
 
   void setTireGrip(int gripFactor);
 
   int stop(int overDistance) throws CannotStopException;
}
 
public interface Motorable {
   int injectGasoline(int mlOfFuel);
}
 
public interface Stoppable {
   int applyBrakes() throws PadException, RotorException, WetRoadException;
}

So we've defined 3 interfaces. Let's say that I'm really interested in a case where I test how the car reacts to different stopping conditions. Now, I'm demonstrating this in Java, so I'll use syntax similar to Mockito - but the rules are the same: I'm interested in testing the requirements of the car observing the expected behavior of the brakes in those conditions. When the grip is set low, we expect the braking system to respond negatively and lock up.

We'll also assume for now that I've stubbed out a skeletal implementation of the Car interface (meaning that everything throws a NotImplementedException for the time being).

@Test
public void testWetRoadConditionsWithLowFriction() {
 
   // arrange
   Stoppable s = mock(Stoppable.class);
   Motorable m = mock(Motorable.class);
 
   Car c = new CarImpl();
   c.setStopAbility(s);
   c.setMotor(m);
   c.setGripFactor(3);
 
   when(s.applyBrakes()).thenThrow(new WetRoadException());
 
   try {
      // act and assert - no real assertion, we're expecting an exception
      c.stop(100);
      fail("Should have seen a CannotStopException - there's not a lot of grip for road when road conditions are wet");
   } catch(CannotStopException e) {
      // do nothing, we're a success!
   }
}

As you can see, we're not actually testing the brakes - we're testing that under the given conditions that when the Stoppable interface throws an exception that prevents our car from stopping successfully that we are throw our own CannotStopException in response. The stoppable interface is a collaborator; we are not interested in this case in unit testing it, we are interested in asuming a known behavior from it, and testing how the stop() ability of the Car implementation reacts to the WetRoadException that we have stubbed.

The alternative in the past would have been to actually create the implementation of Stoppable. But having to unit test both items makes it difficult to isolate implementation issues.

So ultimately young developers, your unit tests need to test a single responsibility and not the responsibility of your collaborators. You may eventually test how the two implementations interact - that is an integration test. Ultimately though, there is more value in testing each individual unit and ensuring that the code is built to the spec of your lightweight design. Then you can isolate integration issues and write tests that specifically address finding integration problems.