by Joseph Yoder & Rebecca Wirfs-Brock

What do we mean by Pragmatic TDD?

Pragmatic Test Driven Development (TDD) is a practical approach to testing that focuses on the bigger picture of how testing best fits into and enhances your team’s software development practices. Rather than insisting that developers only write a lot of unit tests, you need to find a testing strategy that gives you higher quality software. You need to determine how testing best fits into your development context with your developers for your kind of software.

The typical approach to TDD usually focuses on having developers write many unit tests that may or may not add value. Instead, we recommend you adopt a testing strategy that gives you the most leverage. So, for example, rather than merely writing many unit tests, you can often get more value by defining the appropriate user-level acceptance tests. Testing should drive your development (but not at the expense of every other coding and design practice). One size or one approach for testing does not fit every organization or team.

One thing that has discouraged people from incorporating TDD into their organization is the common misperceptions that tests should always be written first, before writing any production code, and, that tests and code should be developed in many tiny increments. We believe that TDD is more about thinking carefully about how best to validate that your software meets your requirements. Testing and validation should drive your development process (that’s why we are fans of being Test Driven), but we think there is so much more to testing than writing lots of unit tests.

What do we mean by different testing rhythms?

We believe that you should pay attention to testing and that it should be an integral part of your daily programming practice. But we don’t insist that you always evolve tests along with your code in many short cycles. Some find it more natural to outline some tests first, and use those test scenarios to guide them as they write code. Once they’ve completed a “good enough” implementation that supports the test scenarios, they then write those tests and incrementally fix any bugs as they go. As long as you don’t write hundreds of lines of code without any testing, we think this style is OK too (and we don’t insist on one style over the other).

What are the testing practices you should consider?

There’s a lot to becoming proficient at TDD. Developing automated test suites, refactoring and reworking tests to eliminate duplication, and testing for exceptional conditions, are just a few. Additionally, acceptance tests, smoke tests, integration, performance and load tests support incremental development as well. If all this testing sounds like too much work, well…let’s get practical. Testing shouldn’t be done just for testing’s sake. Instead, the tests you write should give you leverage to confidently change and evolve your code base and validate the requirements of the system. That’s why it is important to know what to test, what not to test, and when to stop testing.

So, where should you start?

It is important to establish a team testing culture. Get the team on board using similar techniques and tools. Try some different approaches and then as a group reflect on what you’ve learned (have a retrospective). If you are starting a new project you might take a quite different approach than you would with an existing code base. It’s important to not get overwhelmed. Pick an area you want to focus on. For example, it’s much easier to write unit tests for new functionality. But sometimes you want to focus on writing tests for existing code that is buggy or needs to be modified. This can be more difficult. Maybe you want to concentrate on developing integration tests and automating them first (so that you can streamline your build and deploy process). It all depends on where you want to invest first. Just start modestly, grow your testing practices, and measure the impacts of your testing effort and benefits as you go. Of course the most important thing is to start somewhere and have testing become an important part of your development process.

The Refactory, Inc. principal Joseph Yoder & The Refactory, Inc. associate Rebecca Wirfs-Brock will be hosting a Pragmatic Test-driven Development course January 25-27, 2012 in the Portland Metro area.     Register Now!

Joseph Yoder and Rebecca Wirfs-Brock will teach a Pragmatic TDD public course in Tigard, Oregon.

Course Info:

Courtyard Marriott – Tigard
15686 SW Sequoia Parkway
Tigard, OR 97224

First quarter of 2012

Test-driven development (TDD) means writing unit tests along with production code. It leads to modular, flexible and extensible code. Many aspire to follow TDD practices however few know how to do so effectively. Join Joseph Yoder, founder of the Refactory and Rebecca Wirfs-Brock, inventor of Responsibility-Driven Design as you learn Pragmatic TDD. In this 3 day intensive course you’ll learn several natural rhythms of testing, design and programming, uncover how refactoring affects tests, and see how acceptance and system quality tests support and enhance core TDD practices.

Limited space. Register for the Course Today!

Hugo Ferreira is a fellow AOM enthusiast. He and I have collaborated throughout the years, so when he asked me to write a forward for his thesis I did so with honor. I recently traveled to Portugal to sit on the jury of Hugo’s dissertation defense. The experience was a great one and I thought I would share the forward I wrote for his dissertation. He defended his dissertation elegantly and passed with distinction.

Hugo Ferreira’s Dissertation Forward

Over the last decade it has become extremely important for systems to be able to more quickly adapt to changing business requirements. Because of this there has been an evolution of the way we develop and think about building systems. For example, Agile processes have evolved as a means to try to build systems more quickly. But when working on Agile projects, developers can become overwhelmed with the rate of requirements change. The ease with which requirements can change encourages users to overwhelm us with requests for features. The result: Featuritis, which can promotes hasty construction of poorly designed software to support those features. The design of an expressive domain model might get lost in the rush to write working code. Adaptive Object-Models (AOMs) support changeable domain modules by casting business rules as interpreted data and representing objects, properties and relationships in external declarations. At first glance, AOM systems seem to contradict Agile values. Yet we find that under the right conditions, an AOM architecture has made our users happier and has given them the ability to control the pace of change. It can be the ultimate in agility!

This thesis entitled “Adaptive Object-Modeling: Patterns, Tools, and Applications” by Hugo José Sereno Lopes Ferreira has taken the next step in state of art research on best practices on building these types of dynamic systems. This work illustrates the necessity of software to adapt and change at sometimes rapid speeds. Hugo’s addition of seven key patterns brings together years of study and produce formalized patterns as an important contribution to the AOM community. The thesis also brings real world problems to light and centers much of the discussion on the inherent flaws of much of today’s software design practices.

The work reveals much about the current state of Adaptive Object Model practices in industry. I found the thesis to be a quality entry into the current AOM research and very enlightening for in the software community building these types of architectures. The review of AOM architectural style, the patterns catalogue, the outline of the reference architecture for AOMs along with an example implementation makes the work very relevant and informative, as well as a pleasure to read. Additionally the case studies highlight the common issues and problems addressed by AOMs along with proving AOMs exist as a common solution for these types of systems.

I look forward to future collaboration with Hugo on this topic area and it my pleasure to strongly recommend this work to architects and developers that are building these types of dynamic architectures.

I recently traveled to the SATURN 2011 conference in San Francisco. The Software Engineering Institute hosted the conference. Rebecca gave a talk entitled “Agile Adoption, Does It Have To Be All in Or Fold?”

In her SATURN 2011 IEEE Software plenary talk, Rebecca Wirfs-Brock presented case studies of experience reports from the Agile Conference to illustrate various ways in which people perceive what it means to be Agile.

I also gave a Plenary talk entitled, “Big Ball of Mud: Is This the Best that Agile Can Do?”

It’s a myth that Agile doesn’t support design–it’s ok to have good design. Good proven practices and patterns can help. Imitate or use proven quality techniques. You can escape from the spaghetti-code jungle. Have to commit to architecture. “SEI has done more for keeping mud out of our lives than Agile ever has.”

 

I’ve recently returned from SPLASH 2010 and QCon 2010 held in San Francisco. Both conferences rewarded me with the opportunity to meet and greet plenty of AOM supporters. I was fortunate enough to host a tutorial named: Rulemakers and Toolmakers: Adaptive Object Models as Agile Division of Labor with Rebecca Wirfs-Brock.

Adaptive Object Model Tutorial Description

The tutorial explores the AOM Architecture along with an Agile development process for developing them. At the outset, we encourage our clients to bombard us with feature requests. They rain down the ideas onto the development team, overwhelming them. It’s creates what we refer to as “featureitis”. In order to deal with featureitis, we develop a more adaptable system thus allowing the user to make controlled changes like which features they want to use and the evolution of the rules along with the products and services they need. The AOM architecture results in a very Adaptable system that can ultimately help the organization be very Agile.

Open Source Adaptive Object Model Examples

We plan to have some papers and open source implementations on AOMs updated on the site. We currently offer a few AOM examples, but will be expanding in the near future. If you have any AOM examples you have available online, we would be happy to link out to them.

We are very interested in the AOM examples you have implemented with your work. Further discussion in the comment section of this post.

Agile Joe

Adaptive Object Models research and implementation has been a passion of mine for a long time, so it was only natural that I build the domain based on this interest. The AOM site has evolved through the years, to its current iteration. I’m excited to begin blogging about Adaptive Object Model development, research, and implementation. I’ll be enlisting the help of many industry leaders in AOM development, design, and integration. You should be able to spot a few of the authors from my Meta-Friends page.

The AOM blog will be discussing all things related to the topic. This will include General news, AOM Applications, Patterns, Tutorials, and Events. We’ll add more topics as we continue.

I want to make this blog a community effort, so we’ll be introducing the ability for visitors to post their own thoughts and experiences with AOM related topics.

For now, you’ll have to grab our RSS feed to stay on top of the developments. Afterall, things may adapt and change.

Keep on Reflecting!