|By Bill Dudney||
|December 8, 2004 12:00 AM EST||
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.
|Femi 02/16/05 02:05:35 PM EST|
Very nice tool, big question... is there a community edition that can be used to 'infect' those of us without deep pockets with the joy of developer testing?
A free edition of Agitator would go a long way to spreading the message. They can remove the bells and whistles and just give the bare bones to the rest of us. I gave up using Rational Rose because while the corporations I work for can afford it, my little startup company cannot (and don't preach to me about 'investment' unless you're willing to give me a contract!)
We’ve worked with dozens of early adopters across numerous industries and will debunk common misperceptions, which starts with understanding that many of the connected products we’ll use over the next 5 years are already products, they’re just not yet connected. With an IoT product, time-in-market provides much more essential feedback than ever before. Innovation comes from what you do with the data that the connected product provides in order to enhance the customer experience and optimize busi...
May. 1, 2016 05:00 PM EDT Reads: 949
Up until last year, enterprises that were looking into cloud services usually undertook a long-term pilot with one of the large cloud providers, running test and dev workloads in the cloud. With cloud’s transition to mainstream adoption in 2015, and with enterprises migrating more and more workloads into the cloud and in between public and private environments, the single-provider approach must be revisited. In his session at 18th Cloud Expo, Yoav Mor, multi-cloud solution evangelist at Cloudy...
May. 1, 2016 04:30 PM EDT Reads: 1,451
In his session at @ThingsExpo, Chris Klein, CEO and Co-founder of Rachio, will discuss next generation communities that are using IoT to create more sustainable, intelligent communities. One example is Sterling Ranch, a 10,000 home development that – with the help of Siemens – will integrate IoT technology into the community to provide residents with energy and water savings as well as intelligent security. Everything from stop lights to sprinkler systems to building infrastructures will run ef...
May. 1, 2016 04:00 PM EDT Reads: 881
SYS-CON Events announced today that Enzu, a leading provider of cloud hosting solutions, will exhibit at SYS-CON's 18th International Cloud Expo®, which will take place on June 7-9, 2016, at the Javits Center in New York City, NY. Enzu’s mission is to be the leading provider of enterprise cloud solutions worldwide. Enzu enables online businesses to use its IT infrastructure to their competitive advantage. By offering a suite of proven hosting and management services, Enzu wants companies to foc...
May. 1, 2016 03:15 PM EDT Reads: 1,005
So, you bought into the current machine learning craze and went on to collect millions/billions of records from this promising new data source. Now, what do you do with them? Too often, the abundance of data quickly turns into an abundance of problems. How do you extract that "magic essence" from your data without falling into the common pitfalls? In her session at @ThingsExpo, Natalia Ponomareva, Software Engineer at Google, will provide tips on how to be successful in large scale machine lear...
May. 1, 2016 01:45 PM EDT Reads: 1,202
SYS-CON Events announced today that Stratoscale, the software company developing the next generation data center operating system, will exhibit at SYS-CON's 18th International Cloud Expo®, which will take place on June 7-9, 2016, at the Javits Center in New York City, NY. Stratoscale is revolutionizing the data center with a zero-to-cloud-in-minutes solution. With Stratoscale’s hardware-agnostic, Software Defined Data Center (SDDC) solution to store everything, run anything and scale everywhere...
May. 1, 2016 01:30 PM EDT Reads: 1,559
Digital payments using wearable devices such as smart watches, fitness trackers, and payment wristbands are an increasing area of focus for industry participants, and consumer acceptance from early trials and deployments has encouraged some of the biggest names in technology and banking to continue their push to drive growth in this nascent market. Wearable payment systems may utilize near field communication (NFC), radio frequency identification (RFID), or quick response (QR) codes and barcodes...
May. 1, 2016 01:30 PM EDT Reads: 784
Angular 2 is a complete re-write of the popular framework AngularJS. Programming in Angular 2 is greatly simplified – now it's a component-based well-performing framework. This immersive one-day workshop at 18th Cloud Expo, led by Yakov Fain, a Java Champion and a co-founder of the IT consultancy Farata Systems and the product company SuranceBay, will provide you with everything you wanted to know about Angular 2.
May. 1, 2016 01:00 PM EDT Reads: 1,738
You think you know what’s in your data. But do you? Most organizations are now aware of the business intelligence represented by their data. Data science stands to take this to a level you never thought of – literally. The techniques of data science, when used with the capabilities of Big Data technologies, can make connections you had not yet imagined, helping you discover new insights and ask new questions of your data. In his session at @ThingsExpo, Sarbjit Sarkaria, data science team lead ...
May. 1, 2016 12:45 PM EDT Reads: 787
Unless you don’t use the internet, don’t live in California, or haven’t been paying attention to the recent news… you should be aware that self-driving cars are on their way to becoming a reality. I have seen them – they are real. If you believe in the future reality of self-driving cars, then continue reading on. If you don’t believe in the future possibilities, then I am not sure what to do to convince you other than discuss the very real changes that will roll out with the consumer producti...
May. 1, 2016 12:15 PM EDT Reads: 617
SYS-CON Events announced today that Men & Mice, the leading global provider of DNS, DHCP and IP address management overlay solutions, will exhibit at SYS-CON's 18th International Cloud Expo®, which will take place on June 7-9, 2016, at the Javits Center in New York City, NY. The Men & Mice Suite overlay solution is already known for its powerful application in heterogeneous operating environments, enabling enterprises to scale without fuss. Building on a solid range of diverse platform support,...
May. 1, 2016 12:15 PM EDT Reads: 2,317
SYS-CON Events announced today that Peak 10, Inc., a national IT infrastructure and cloud services provider, will exhibit at SYS-CON's 18th International Cloud Expo®, which will take place on June 7-9, 2016, at the Javits Center in New York City, NY. Peak 10 provides reliable, tailored data center and network services, cloud and managed services. Its solutions are designed to scale and adapt to customers’ changing business needs, enabling them to lower costs, improve performance and focus inter...
May. 1, 2016 12:00 PM EDT Reads: 1,116
You deployed your app with the Bluemix PaaS and it's gaining some serious traction, so it's time to make some tweaks. Did you design your application in a way that it can scale in the cloud? Were you even thinking about the cloud when you built the app? If not, chances are your app is going to break. Check out this webcast to learn various techniques for designing applications that will scale successfully in Bluemix, for the confidence you need to take your apps to the next level and beyond.
May. 1, 2016 11:45 AM EDT Reads: 1,485
See storage differently! Storage performance problems have only gotten worse and harder to solve as applications have become largely virtualized and moved to a cloud-based infrastructure. Storage performance in a virtualized environment is not just about IOPS, it is about how well that potential performance is guaranteed to individual VMs for these apps as the number of VMs keep going up real time. In his session at 18th Cloud Expo, Dhiraj Sehgal, in product and marketing at Tintri, will discu...
May. 1, 2016 11:00 AM EDT Reads: 800
In the world of DevOps there are ‘known good practices’ – aka ‘patterns’ – and ‘known bad practices’ – aka ‘anti-patterns.' Many of these patterns and anti-patterns have been developed from real world experience, especially by the early adopters of DevOps theory; but many are more feasible in theory than in practice, especially for more recent entrants to the DevOps scene. In this power panel at @DevOpsSummit at 18th Cloud Expo, moderated by DevOps Conference Chair Andi Mann, panelists will dis...
May. 1, 2016 11:00 AM EDT Reads: 635