SYS-CON MEDIA Authors: Zakia Bouachraoui, Liz McMillan, Yeshim Deniz, Janakiram MSV, Carmen Gonzalez

Related Topics: Java IoT

Java IoT: Article

Developer Testing Is 'In'

An interview with Alberto Savoia and Kent Beck

A few weeks ago Agitar Software announced that Kent Beck had joined their team. I sat down and talked with Alberto Savoia, CTO, and Kent Beck, Agitar Fellow, to find out what prompted the move and what Agitar is up to that is so exciting.

JDJ: Kent and Alberto, why each other?

Beck: I think the primary motivation for the move is that Agitar is supporting very similar things that I have been working on for a number of years. You have a kind of leverage from working with a commercial company that you just don't have as an individual. The technology is also very interesting.

For 50 years it has been okay for the IT group to be sort of closed and not allow the business side to see what is going on until the end. The trend today is toward more transparency. Developer testing is one form of transparency or accountability. In the past business wrote a check and IT delivered something, but what was delivered was not always sufficient. Developer testing (and thus Agitator and Agitar) is one means of raising the level of transparency and accountability. The other thing is that developer testing makes the developer's job better; it lets you design better; it lets you do your job with confidence; and it lets you sleep better.

Savoia: Agitar probably would not exist if not for Kent and his contributions of XP and JUnit. Since XP is now cool, testing is now by inference cool. I always thought that developer testing is something we should have been doing all along and XP has made it legitimate for developers to test. More important, it is one thing to just say "you should be doing testing"; it's another thing entirely to give developers a tool in the form of JUnit to help them do developer testing.

It's great to have Kent since he is the one who started this whole thing. Also, as we go forward in making developer testing ubiquitous, Kent's vision is going to be extremely influential in the way that we evolve Agitar.

JDJ: Is developer testing a fad?
Developer testing is something that should have been done from day one. For whatever reason developers abdicated this responsibility. Now with XP and JUnit, developer testing is making a comeback, but should have always been here.

Over the past year or so I've talked to literally hundreds of developers and development managers and none of them could make a good argument for not doing developer testing. The thing that comes up though is something I call the developer testing paradox, even though everyone thinks that developer testing is good. It's like motherhood and apple pie - everyone thinks it's a good idea but it's not nearly as widely adopted as it should be. This is the paradox: Why is something so good practiced so infrequently? I believe it's because there are insufficient tools and processes to make developer testing more efficient and effective, and without these processes and tools it will be hard for developer testing to become as widespread as we believe it should be.

The other benefit we feel that you get out of developer testing is early and frequent feedback on your design. The first-order effect is great, a reduction in bugs, but the second-order effect of having better overall designs is probably even more valuable. With developer testing you get early feedback on the coupled (or not) nature of your design. If your design is highly coupled, you'll have complex setup and teardown. If your design is loosely coupled, you'll have a much easier time testing and a more flexible system.

JDJ: Is the developer testing that does exist sufficient?
We have some empirical data that suggests that most IT shops that implement developer testing see around 30% of their developers become "test infected." Even if management decides to stop the unit testing effort, these developers would continue to do developer testing because they have realized the benefits.

The other 70% must have been immunized in their childhoods; the minute the pressure is off to build unit tests, they abandon developer testing and go back to writing lots of code with little testing.

The group who writes tests tends to write good tests, and their tests fail. Meaning that the good tests will find and prevent bugs. On the other hand, the group of developers who don't get test infected, write tests that almost always pass. These tests usually don't find bugs.

JDJ: Is this why we all too often see a system with a large set of developer tests fail when it's delivered to a testing group?
Exactly, this problem has a name: the pesticide paradox. Your code evolves to pass the unit tests; if you don't continue to increase the "dose" of the pesticide (the tests), pretty soon bugs adapt to the tests that you do have.

JDJ: Is developer testing increasing in the enterprise? What are you seeing among your clients?
The rarest of all is the company that decided to do developer testing, trained their whole team, and have been doing developer testing for quite a while, and are seeing success with this method. Usually these teams are led by people who are test infected; thus developer testing becomes part of the culture.

The largest group comprises companies that realize that testing is the correct thing to do. But when they try to implement they run into a set of problems. The primary one is that it takes a lot of time to test code and they don't know where that time will come from.

Finally, there are the companies that want to do developer testing but they just don't know where to start. Perhaps there are a few developers who are test infected but it's not something that is part of the team. I have yet to meet a team that says, "Hey, Alberto, we have two weeks with nothing to do. We were thinking of trying out developer testing." Developers always have something to work on, something to do. Moving to a developer-testing mindset is often difficult to do.

JDJ: In what ways does Agitator help solve these issues that you are seeing?
 The main problem that I encountered when trying to instigate developer testing at Google was the time it takes to write the tests. If developers have to write 300-400 lines of test code to test 100 lines of source code, even though it's the right thing to do, they are making a large investment. The way that Agitator helps with this is by recognizing that much of testing is combinatorial in nature. For example, every if statement in your code needs two tests written. So writing tests by hand is great for particular test cases that you have thought about. Then you want to do exploratory testing and think about all the things that could happen.

I don't believe that code is the correct metaphor for testing. For instance, just like a spreadsheet is the correct metaphor for getting a bunch of calculations done or generating a graph. You don't care about all the stuff that goes on under the hood. You want to give the spreadsheet the input data, a list of formulas, and then have the result. A spreadsheet raises the level of abstraction to the things that you care about. Similarly Agitator raises the level of abstraction of the testing tasks to the components that are important. Those components are the test data and the assertions. The unnecessary distraction of the framework code is below the level of abstraction.

Along those same lines Agitator lowers the barrier to entry for developer testing thus making developer's lives more productive and more fun. In addition the tool also gives a means to measure what is going on inside the project. If you look at what everyone on the team is doing with Agitator and rolled that, you have a much more precise view of what is going on inside.

JDJ: What level of metrics is the Agitator able to provide?
 We have spent a lot of time thinking about metrics. In fact our Dashboard product is all about metrics, and we have learned a lot of valuable lessons. When you want to institute developer testing, it's important to focus on positive metrics, in other words metrics that go up with better testing. Let me give you an example of one of the metrics reported by the Dashboard; we call it "Test Points." Whether you use JUnit or Agitator, every assert statement, for example, asserting that add(2,2) returns 4 is a test point. That is a metric that is positive. As that number grows, we can feel good. This metric is in contrast to traditional metrics like "the number of bugs found." If you are doing developer testing, presumably you won't find a lot of bugs with the tests because the tests help you prevent bugs in the first place.

Another metric that we use is percentage of classes or methods that have tests. Here the goal is very simple: have a test class for each class. There should be symmetry here. Measure how this metric grows as you achieve the goal that you have set for your group, then you can start to add a test for each method. As you achieve the goal you have for the number of methods touched by a test, you can get even more aggressive. However, this positive metric gives the team something positive to focus on and move toward. Instead of measuring your failures, you have favorable measurements to look at.

JDJ: Do you have any metrics regarding the use of Agitator over time? Something like, before developer testing there were so many bugs per 1,000 lines of code and after using developer testing the bug count fell to fewer bugs per 1,000 lines.
We have been doing developer testing on Agitator from the beginning and we currently have more than 20,000 test points for Agitator that run several times a day. It typically discovers a few bugs, and when we do major open-heart surgery on the code it finds many problems that we then fix.

Since we have been doing developer testing from the beginning, it's hard to offer a contrast. I can, however, point you and your readers to a recorded Webinar on our Web site (www.agitar.com) in which Jayson Minard of Abebooks.com talks about their use of Agitator. In a recent quarter they experienced zero downtime because of their use of developer testing and the Agitator. But even so, I still tend to go by gut feelings. The fact that I have 25,000 tests keeping the code clean and, if something goes wrong, I get red flags all over the place, makes me feel a lot better than a particular set of numbers.

JDJ: Do you see the metrics generated by the Dashboard being misused, or is the test-point metric harder to misuse than coverage alone.
I believe in code coverage, but coverage without assertions is like testing a calculator by pushing the buttons for three hours and never looking at the display. I can say that the calculator did not catch on fire but I can't say if it functioned correctly. For example, when an application starts up, you could see as much as 30% code coverage, but you have not discovered that it stated correctly since just starting does not run any assertions. What we do is create a mapping between code coverage and assertion coverage. The theory is that a method is "covered," but if there are no assertions for that method, the coverage does not get counted in the test points metric. Sure it is possible that the method has been tested indirectly, but without a direct test I can't relax and sleep well at night until I have that level of testing. Furthermore if your code cannot be tested at the class and method level your code might not be unit testable and therefore has some likely coupling problems.

JDJ: How does the Agitator fit into a typical developer process?
We ran an experiment (documented at www.developertesting.com) where we did a project test first using JUnit. The interesting thing is that when you do this kind of testing, the developer tends to focus on the positive tests, i.e., 2 * 2 is in fact evaluating to 4, which is natural. However, we always fired up Agitator to help us think about the corner cases that we didn't consider during our typical testing. We found two interesting results. We expected the first; namely that the corner cases that Agitator found were indeed busted, e.g., if I pass a string that is too long/short to this method, the code breaks. The other outcome was that Agitator forced us to think through further refactorings that we did not previously consider. This process is documented in the series of articles on this project at developertesting.com (Agitator-driven refactoring). Using JUnit we thought about "localized" refactorings on particular classes, but in bringing in agitation we saw areas where we should do wider refactorings. It showed us more of the global-level dependencies that were not readily apparent without the agitation process.

JDJ: Where are you headed with the tool set? What's next?
Our vision and one of the reasons we hired Kent Beck is that right now developer testing seems to be the exception rather than the rule. Our goal is to reverse that in the next three to four years. Our product goal is to make Agitator more and more integrated with the development process to assist in the movement toward a major shift into developer testing in the industry.

We are also developing new and interesting ways to display the mountain of information that we gather with the Dashboard. For example, you can see "risky" classes. Risk is a combination of the complexity of the class and the dependencies on that class. With the Dashboard we are headed to more summarization of the information we gather as well as giving people some data on a successful project so that they have something to compare against.

More Stories By Bill Dudney

Bill Dudney is Editor-in-Chief of Eclipse Developer's Journal and serves too as JDJ's Eclipse editor. He is a Practice Leader with Virtuas Solutions and has been doing Java development since late 1996 after he downloaded his first copy of the JDK. Prior to Virtuas, Bill worked for InLine Software on the UML bridge that tied UML Models in Rational Rose and later XMI to the InLine suite of tools. Prior to getting hooked on Java he built software on NeXTStep (precursor to Apple's OSX). He has roughly 15 years of distributed software development experience starting at NASA building software to manage the mass properties of the Space Shuttle.

Comments (1)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Latest Stories
ShieldX's CEO and Founder, Ratinder Ahuja, believes that traditional security solutions are not designed to be effective in the cloud. The role of Data Loss Prevention must evolve in order to combat the challenges of changing infrastructure associated with modernized cloud environments. Ratinder will call out the notion that security processes and controls must be equally dynamic and able to adapt for the cloud. Utilizing four key factors of automation, enterprises can remediate issues and impro...
CloudEXPO has been the M&A capital for Cloud companies for more than a decade with memorable acquisition news stories which came out of CloudEXPO expo floor. DevOpsSUMMIT New York faculty member Greg Bledsoe shared his views on IBM's Red Hat acquisition live from NASDAQ floor. Acquisition news was announced during CloudEXPO New York which took place November 12-13, 2019 in New York City.
In an age of borderless networks, security for the cloud and security for the corporate network can no longer be separated. Security teams are now presented with the challenge of monitoring and controlling access to these cloud environments, at the same time that developers quickly spin up new cloud instances and executives push forwards new initiatives. The vulnerabilities created by migration to the cloud, such as misconfigurations and compromised credentials, require that security teams t...
Cloud is the motor for innovation and digital transformation. CIOs will run 25% of total application workloads in the cloud by the end of 2018, based on recent Morgan Stanley report. Having the right enterprise cloud strategy in place, often in a multi cloud environment, also helps companies become a more intelligent business. Companies that master this path have something in common: they create a culture of continuous innovation. In his presentation, Dilipkumar Khandelwal outlined the latest...
The graph represents a network of 1,329 Twitter users whose recent tweets contained "#DevOps", or who were replied to or mentioned in those tweets, taken from a data set limited to a maximum of 18,000 tweets. The network was obtained from Twitter on Thursday, 10 January 2019 at 23:50 UTC. The tweets in the network were tweeted over the 7-hour, 6-minute period from Thursday, 10 January 2019 at 16:29 UTC to Thursday, 10 January 2019 at 23:36 UTC. Additional tweets that were mentioned in this...
The use of containers by developers -- and now increasingly IT operators -- has grown from infatuation to deep and abiding love. But as with any long-term affair, the honeymoon soon leads to needing to live well together ... and maybe even getting some relationship help along the way. And so it goes with container orchestration and automation solutions, which are rapidly emerging as the means to maintain the bliss between rapid container adoption and broad container use among multiple cloud host...
Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more business becomes digital the more stakeholders are interested in this data including how it relates to business. Some of these people have never used a monitoring tool before. They have a question on their mind like "How is my application doing" but no id...
The term "digital transformation" (DX) is being used by everyone for just about any company initiative that involves technology, the web, ecommerce, software, or even customer experience. While the term has certainly turned into a buzzword with a lot of hype, the transition to a more connected, digital world is real and comes with real challenges. In his opening keynote, Four Essentials To Become DX Hero Status Now, Jonathan Hoppe, Co-Founder and CTO of Total Uptime Technologies, shared that ...
Is advanced scheduling in Kubernetes achievable?Yes, however, how do you properly accommodate every real-life scenario that a Kubernetes user might encounter? How do you leverage advanced scheduling techniques to shape and describe each scenario in easy-to-use rules and configurations? In his session at @DevOpsSummit at 21st Cloud Expo, Oleg Chunikhin, CTO at Kublr, answered these questions and demonstrated techniques for implementing advanced scheduling. For example, using spot instances and co...
Platform-as-a-Service (PaaS) is a technology designed to make DevOps easier and allow developers to focus on application development. The PaaS takes care of provisioning, scaling, HA, and other cloud management aspects. Apache Stratos is a PaaS codebase developed in Apache and designed to create a highly productive developer environment while also supporting powerful deployment options. Integration with the Docker platform, CoreOS Linux distribution, and Kubernetes container management system ...
Because Linkerd is a transparent proxy that runs alongside your application, there are no code changes required. It even comes with Prometheus to store the metrics for you and pre-built Grafana dashboards to show exactly what is important for your services - success rate, latency, and throughput. In this session, we'll explain what Linkerd provides for you, demo the installation of Linkerd on Kubernetes and debug a real world problem. We will also dig into what functionality you can build on ...
DevOps is a world surrounded by information, starting from a single commit and ending in roll out to production. In this talk, I'll introduce you to the world of Taboola DevOps data collection, to better understand what goes on under the hood. The system we've developed in-house helps us collect and analyse the entire DevOps process from the very first commit all the way to production. It provides us a full clear view with a drill-down toolset that helps keep us away from the dark side. ...
In his session at 20th Cloud Expo, Mike Johnston, an infrastructure engineer at Supergiant.io, will discuss how to use Kubernetes to setup a SaaS infrastructure for your business. Mike Johnston is an infrastructure engineer at Supergiant.io with over 12 years of experience designing, deploying, and maintaining server and workstation infrastructure at all scales. He has experience with brick and mortar data centers as well as cloud providers like Digital Ocean, Amazon Web Services, and Rackspace....
After years of investments and acquisitions, CloudBlue was created with the goal of building the world's only hyperscale digital platform with an increasingly infinite ecosystem and proven go-to-market services. The result? An unmatched platform that helps customers streamline cloud operations, save time and money, and revolutionize their businesses overnight. Today, the platform operates in more than 45 countries and powers more than 200 of the world's largest cloud marketplaces, managing mo...
Containerized software is riding a wave of growth, according to latest RightScale survey. At Sematext we see this growth trend via our Docker monitoring adoption and via Sematext Docker Agent popularity on Docker Hub, where it crossed 1M+ pulls line. This rapid rise of containers now makes Docker the top DevOps tool among those included in RightScale survey. Overall Docker adoption surged to 35 percent, while Kubernetes adoption doubled, going from 7% in 2016 to 14% percent.