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!

As I finish this last day in South Korea, I’m reminded of the entire trip. It started a few months ago, with talks held in the balmy Florida heat. Today they’re fnished and I’m grateful to have been a part of such an exciting trip that took me literally halfway across the world to teach the principles that I support and have such passion for.

I traveled to South Korea on the Fourth of July. I went knowing that I would be teaching a TDD course to a talented group of developers. The TDD course was tailored to the medical domain. I have worked within the medical domain on several projects throughout the years. The course went well and a few surprises happened as well.

I got invited to a software architecture conference. I gave a keynote address at the conference. The entire talk was translated for the largely Korean speaking audience. The talk was using “Meta to Scale the Cloud.” The conference was called Korea Software Architecture Summit (KSAS).

It’s good to see the Agile movement taking root in South Korea. I met with the Seoul Agile Users Group and gave a talk on “Test Driven Development, Refactorinng, Patterns and Adaptive Object Models.” The enthusiasm was clearly visible at the conference. People were engaged. I look forward to making my way back to South Korea someday.

I’m in Douro Valley, Portugal for the MetaPLoP conference. I’m excited to see the results of this weekend’s efforts. The conference will be mining patterns for the best of the lot. We’ll be talking, discussing, and reviewing patterns related to Meta-Architectures, Adaptive Object Models, and Reflective Systems. The best patterns should stand out from the rest, being set apart by their merits.

I’m excited to be here with Hugo Sereno Ferreira, Filipe Correia, Eduardo Guerra, Ademar Aguiar, Lior Schachter, Rebecca Wirfs-Brock, and Allen Wirfs-Brock. I’m looking forward to a great event. I will update with any news that comes out of the talks.

I’m currently at Agile Portugal. The conference will be over soon and then it’ll be time for MetaPLoP in Douro Valley. I was excited today to give my “Rulemakers and Toolmakers: Adaptive Object Models as Agile Division of Labor” tutorial. Rebecca Wirfs-Brock and I have worked hard to refine and enliven this tutorial. You can read more about it on the Agile PT page. We think it was a total success.

The big surprise of the day happened when I was asked to speak in place of Dave Thomas who couldn’t make the conference.  The talk was titled, “Lean – The Foundation for Agility Increase Value, Reduce Waste, Improve Flow.” I think it went well too. The focus on Agile methods speaks to a lot of my own experience. If you were at the talk, I would love to hear your comments.

The first Meta PLoP is scheduled for June 24th to 26th, 2011 in Portugal. Here’s the description of the conference from the MetaPLoP.org website:

MetaPLoP is a PLoP-like gathering focused on the specific topic of meta-architectures, adaptive object-models, and reflective systems. The main goal of MetaPLoP is to “mine” the best patterns that have been written about these topics and organize them into a common theme that can tell a great story that we can publish in a focused issue of the TPLoP Journal.

The conference will have attendees from all over, including Joseph Yoder, Hugo Sereno Ferreira, Filipe Correia, Ademar Aguiar, Rebecca Wirfs-Brock, and Allen Wirfs-Brock. Other notable guests may be in attendance as well. Will you be?

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.”

 

Hello! Since this is my first post, let me introduce myself. My name is Reza Razavi. I’m currently heading the research and innovation efforts of AAS that I co-founded in 2007. I’ve been involved in developing industrial AOMs since 1993. In particular, I implemented a software system for calibrating bore gauges that allows domain experts defining new gage types, their attributes and calibration procedure themselves, and make them readily (without compilation) available for use by calibration operators. Calibration procedures are defined as a composition of atomic measurement and calculation services. This allowed our customer to reduce the cost of their maintenance by at least a factor of ten, while being able to easily adapt their gauge calibration procedures to specific customer needs. Then, I switched to academic research and have been collaborating with Ralph Johnson and Joe Yoder since the early days they initiated research on AOMs.

Now, as an early adopter of AOMs for both industrial and academic software projects, I would like to react to the Rebecca’s tweet/retort to Michael Feathers (@mfeathers) where she stresses “Meta-architectures aren’t “old” technology…they’re “proven” technology…”.

For example, here at AAS we have developed a novel software platform that allows developing web-enabled AOMs by reuse and extension. We are currently working on large scale development of such AOMs to address the need for individualized and adaptive web-based solutions to populations like the elderly. The elderly need customized care. Imagine that each person had a computer in the cloud that watched over him or her. We propose adaptive web servers to empower end-users and their communities, like caregivers, to give themselves an active part in the design and customization of their web-based services. So, once more, meta-architectures and AOMs have proven powerful in supporting business applications with highly-demanding dynamic adaptivity requirements.

It should also be emphasized that with AAS-Platform, AOMs figure today at the very heart of a unique solution to the latest approaches to service delivery and business development as explained in The Power of Pull , where end-users and their communities are perceived themselves as valuable actors of service innovation and personalization, and empowered to assume their responsibilities.

Furthermore, as it is emphasized by David Siegel in his Open Letters to Apple Board Members, and Sergey Brin, Larry Page, and Eric Schmidt (Google), “the future of media, entertainment, productivity, and business tools is in the cloud”. However, “the power shift of the 21st century is not to use the cloud to re-create our desktop tools but to build data-driven ecosystems that take us far beyond what we could have done without the power of the cloud.”. David Siegel, urges that to build “data-driven ecosystems”, and to “empower people to collect and use their own data for themselves” (in alignment with the “pull” model), web technologies shall start by “getting the data out of the apps”.

AAS-Platform has been designed and implemented with these requirements and service delivery model as primary considerations. It enables the large-scale development of websites like Yahoo! Pipes by regular application developers, where the active and collaborative participation of end-users (even non-technical people) as partners in the service innovation and delivery processes is supported by design.

Specifically, AAS-Platform allows Web-based AOMs that maintain an “open user activity flow model”, and allow end-users to interact with and modify that model (which is otherwise “hard-coded” by programmers). Every piece of meta-data and data that end-users care about may be accessed via dedicated atomic services and reused when assembling new services, thereby contributing to the concept of “data-driven ecosystems”. Read more …

My name is Atzmon Hen-tov and I am the Chief Software Architect at Pontis (www.pontis.com).  I would like to share with you my experience with AOM and the business benefits Pontis gains from using AOM. Pontis was lately nominated as the fastest growing company in the Telecommunication sector in Europe (see Deloitte Technology Fast 500 EMEA).

First, some background about Pontis. Pontis provides Targeted Marketing in the Telecommunications and Cable-TV domains.  Targeted Marketing means that end-users get only offers and promotions that are relevant to them and they get them at the right time.  For example, just before you load money to your pre-paid phone, we’ll offer you to extend the amount and get a special bonus (e.g., 100 free short messages).  We deploy our systems at the customer premises and typically integrate with 10-15 customer systems.  Each customer has a distinct set of systems we need to integrate with and a lot of other differences from other customers.

In Pontis, we follow the rule – “if it changes a lot, move it to the GUI”.  The motivation behind this rule is to reduce changes in Java/Scripting/Technical code and allow our system users to define, configure, tune and operate the system without needing to get help from technical people.  Getting help from technical people often means a new, full blown software delivery.  Although many companies practice Continuous-Delivery these days (See this book for a great reading on the subject), it is better to avoid code changes and the consequent risks and project overheads.

We discovered that “what changes a lot” is the customer domain model.  That is, each customer has different attributes for the subscriber (“Subscriber” is “customer” in Telco slang), different types of price-plans, and different structure of events (e.g., for voice-call, money charge, short-message send).   At first, we developed the generic part of the system (the part that is used by all customers) in Java and then defined the customer specific parts in DSLs (Domain Specific Languages) from which we generated Java code.  When the model grew to more than 1000 classes, this proved to be a poor choice.  After every change in a DSL you had to wait 20+ minutes for code-generation, compilation, packaging, deployment, etc.  In other words, the Edit-Execute Cycle became really bad.

Enter AOM.

AOM is an interpretive approach; the model (meta-data) is interpreted and executed at runtime.  No code generation, no more “let’s make a coffee or two and come back to see if the build is done”.  This doesn’t come out easily.  You need to write sophisticated code that accounts for all the variability you give the end-users in defining the domain model.  Luckily the Adaptive Object Model site provides you with handful of patterns to do just that.

We started with a few variability points, that is, model classes that can be extended in the AOM GUI and added more as needs were identified.  Today we have a rich AOM application with 50+ variability points that allow non developers to fully customize the application model for each new customer.

AOM is so critical to our business model that we have an official AOM Engineer role in Pontis whose responsibilities are to customize the generic product and to maintain the customer’s AOM metadata in configuration management.  By having non-developer AOM engineers we gain better communication between the stakeholders; AOM engineers are not occupied with technical stuff (Java, Patterns, Performance, third-party libraries, etc.) and talk the language of the business.  But since they are the actual implementer they close things up with the developers to the very last detail (e.g. when a new generic feature is required to implement a business use-case).

Looking back at the last year or so, I can confidently say that AOM made a big difference in Pontis. A difference in the way we work, in the way we deliver software, and in the way we think; most notably in the frequency and quality of our deliveries.   Whenever a new requirement arises, the first thing we do is try to figure out how it can be satisfied by AOM-only changes. If it’s indeed possible (and an impressive amount of times it is; I actually have some numbers on this, but it’s a story for another day), the AOM engineer can implement the change via the GUI and spare the cycle of Java delivery.

We’re still learning as we go. There are many challenges, not all of them technical – in particular, we haven’t worked out the kinks of merging changes between different environments. I invite you to learn together with us – come back here for more!