ryan norris

I’ve been writing a bit about Google Web Toolkit lately. It undeniably is disrupting traditional browser-based RIA development. But it does lack some features out of the box that most developers have grown accustomed to from frameworks like Flex and Ext. Field validation is one such feature. While the gwt-validation project exists to solve this very problem, an approach leveraging a good chunk of the existing GWT infrastructure can give you a robust, test-driven, and MVP-friendly approach for validation. (more…)

As much as I love automated testing, I have come to live with the fact that teams migrating from waterfall approaches to development to SCRUM often try to maintain the team structures they are familiar with.  At times, this typically means an engineering staff that sucks at writing tests, and a QA staff that is still very much attuned to the finer grained edge and corner cases.  Each of these parts of your team adds value to a SCRUM project.  Integrating them to avoid bottlenecks, stay lean, and deliver with quality is a clever trick.

(more…)

I recently posted about why I think mocks are simply the easiest way to get the most bang for your buck in automated software testing.  But integrating it as part of a process is hard, and teaching it is even harder.  Young developers seem to have a hard time grasping the idea of testing isolated units of code.  I’ll confess – for a long time, much of my unit testing involved setting up the appropriate test environments – Spring containers for persistence units, test databases, you name it.  It’s expensive to test this way, and there are only so many situations when integration tests are valuable.  On lean, agile teams – code coverage isn’t held in as high regard as having working software.  On lean, agile teams – tests are a driver towards design, but they do need to be rooted in some level of initial thought on how a problem needs to be solved.

(more…)

About two years back when I started getting completely fascist about test-driven development, the complexity was always “gee, i have an application container and I need to involve it in my unit tests so that I can get full test coverage !!111oneeleventy.”

This typically meant providing a real collaborator, like a PersistenceUnit in Java, so that I could test trivial operations like persisting an entity.  At the time, I challenged a manager on this:

What are we really testing?  Are we testing OUR requirement, or are we testing something we should reasonably expect Hibernate to do on the basis of our initial technology selection?

Code coverage I believe is pretty overrated.  No one cares whether or not you can prove your method to persist an entity works because the developers of Hibernate/TopLink/LINQ to SQL have already proved this through their unit tests. What you are building when you write a test that actually checks the database to see if your middleware used a pre-packaged object-relational manpping framework correctly is an integration test.  There’s certainly value to integration testing with data access layers, particularly when difficult to test components of your middleware (like stored procedures and triggers) are involved.  Saving that however, the focus of test-driven development – namely unit tests, should be on the business logic that is proprietary to your applicatiom, be it the front-end or the middle tier.

Now, suffice to say that to a good number of developers and architects this isn’t news, but if you really want to isolate the code which you wrote that is specific to your business rules and requirements – mocking frameworks are the way to go.  Particularly in an Agile project where we can readily identify certain injected dependencies (like an EntityManager, for example) as a collaborator of the class under test, your unit test is really interested in asking the question based on this interaction with this external component, how should I expect my logic to react?

In these scenarios of course, I mock or stub the EntityManager.  In the past, a fool like me would have tried to load a container within my unit test environment.  This is actually an integration test, in addition to the fact that it is costly and doesn’t add the value a truly isolated unit test which focuses on the code you wrote does.

In .Net, RhinoMocks is scalding hot with it’s supprt for mocking through lambda’s.  In JEE, I’ve fallen in love with Mockito.

So, stop worrying about how you can get JBoss running so that your CI environment can execute inside of it.  Instead, use mocks to give your code the resources it needs to vet out the conditions in your own code that you want to test.