|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!)
Container technology is sending shock waves through the world of cloud computing. Heralded as the 'next big thing,' containers provide software owners a consistent way to package their software and dependencies while infrastructure operators benefit from a standard way to deploy and run them. Containers present new challenges for tracking usage due to their dynamic nature. They can also be deployed to bare metal, virtual machines and various cloud platforms. How do software owners track the usag...
Aug. 5, 2015 07:00 AM EDT Reads: 297
In their session at 17th Cloud Expo, Hal Schwartz, CEO of Secure Infrastructure & Services (SIAS), and Chuck Paolillo, CTO of Secure Infrastructure & Services (SIAS), provide a study of cloud adoption trends and the power and flexibility of IBM Power and Pureflex cloud solutions. In his role as CEO of Secure Infrastructure & Services (SIAS), Hal Schwartz provides leadership and direction for the company.
Aug. 4, 2015 06:45 PM EDT Reads: 242
There are many considerations when moving applications from on-premise to cloud. It is critical to understand the benefits and also challenges of this migration. A successful migration will result in lower Total Cost of Ownership, yet offer the same or higher level of robustness. In his session at 15th Cloud Expo, Michael Meiner, an Engineering Director at Oracle, Corporation, analyzed a range of cloud offerings (IaaS, PaaS, SaaS) and discussed the benefits/challenges of migrating to each offe...
Aug. 4, 2015 06:45 PM EDT Reads: 220
SYS-CON Events announced today that the "Second Containers & Microservices Expo" will take place November 3-5, 2015, at the Santa Clara Convention Center in Santa Clara, CA. Containers and microservices have become topics of intense interest throughout the cloud developer and enterprise IT communities.
Aug. 4, 2015 05:30 PM EDT Reads: 105
As organizations shift towards IT-as-a-service models, the need for managing and protecting data residing across physical, virtual, and now cloud environments grows with it. CommVault can ensure protection and E-Discovery of your data – whether in a private cloud, a Service Provider delivered public cloud, or a hybrid cloud environment – across the heterogeneous enterprise. In his session at 17th Cloud Expo, Randy De Meno, Chief Technologist - Windows Products and Microsoft Partnerships at Com...
Aug. 4, 2015 05:00 PM EDT Reads: 112
The Software Defined Data Center (SDDC), which enables organizations to seamlessly run in a hybrid cloud model (public + private cloud), is here to stay. IDC estimates that the software-defined networking market will be valued at $3.7 billion by 2016. Security is a key component and benefit of the SDDC, and offers an opportunity to build security 'from the ground up' and weave it into the environment from day one. In his session at 16th Cloud Expo, Reuven Harrison, CTO and Co-Founder of Tufin,...
Aug. 4, 2015 03:00 PM EDT Reads: 577
Scrum Alliance has announced the release of its 2015 State of Scrum Report. Almost 5,000 individuals and companies worldwide participated in this year's survey. Most organizations in the market today are still leading and managing under an Industrial Age model. Not only is the speed of change growing exponentially, Agile and Scrum frameworks are showing companies how to draw on the full talents and capabilities of those doing the work in order to continue innovating for success.
Aug. 4, 2015 02:45 PM EDT
SYS-CON Events announced today that MobiDev, a software development company, will exhibit at the 17th International Cloud Expo®, which will take place November 3–5, 2015, at the Santa Clara Convention Center in Santa Clara, CA. MobiDev is a software development company with representative offices in Atlanta (US), Sheffield (UK) and Würzburg (Germany); and development centers in Ukraine. Since 2009 it has grown from a small group of passionate engineers and business managers to a full-scale mobi...
Aug. 4, 2015 02:00 PM EDT Reads: 395
Between the compelling mockups and specs produced by your analysts and designers, and the resulting application built by your developers, there is a gulf where projects fail, costs spiral out of control, and applications fall short of requirements. In his session at @DevOpsSummit, Charles Kendrick, CTO and Chief Architect at Isomorphic Software, presented a new approach where business and development users collaborate – each using tools appropriate to their goals and expertise – to build mocku...
Aug. 4, 2015 01:30 PM EDT Reads: 105
SYS-CON Events announced today that VividCortex, the monitoring solution for the modern data system, will exhibit at the 17th International Cloud Expo®, which will take place on November 3–5, 2015, at the Santa Clara Convention Center in Santa Clara, CA. The database is the heart of most applications, but it’s also the part that’s hardest to scale, monitor, and optimize even as it’s growing 50% year over year. VividCortex is the first unified suite of database monitoring tools specifically desi...
Aug. 4, 2015 12:00 PM EDT Reads: 117
Graylog, Inc., has added the capability to collect, centralize and analyze application container logs from within Docker. The Graylog logging driver for Docker addresses the challenges of extracting intelligence from within Docker containers, where most workloads are dynamic and log data is not persisted or stored. Using Graylog, DevOps and IT Ops teams can pinpoint the root cause of problems to deliver new applications faster and minimize downtime.
Aug. 4, 2015 11:45 AM EDT
As Marc Andreessen says software is eating the world. Everything is rapidly moving toward being software-defined – from our phones and cars through our washing machines to the datacenter. However, there are larger challenges when implementing software defined on a larger scale - when building software defined infrastructure. In his session at 16th Cloud Expo, Boyan Ivanov, CEO of StorPool, provided some practical insights on what, how and why when implementing "software-defined" in the datacent...
Aug. 4, 2015 11:30 AM EDT Reads: 125
Learn how you can use the CoSN SEND II Decision Tree for Education Technology to make sure that your K–12 technology initiatives create a more engaging learning experience that empowers students, teachers, and administrators alike.
Aug. 4, 2015 09:30 AM EDT Reads: 123
Mobile, social, Big Data, and cloud have fundamentally changed the way we live. “Anytime, anywhere” access to data and information is no longer a luxury; it’s a requirement, in both our personal and professional lives. For IT organizations, this means pressure has never been greater to deliver meaningful services to the business and customers.
Aug. 4, 2015 08:45 AM EDT Reads: 265
In a recent research, analyst firm IDC found that the average cost of a critical application failure is $500,000 to $1 million per hour and the average total cost of unplanned application downtime is $1.25 billion to $2.5 billion per year for Fortune 1000 companies. In addition to the findings on the cost of the downtime, the research also highlighted best practices for development, testing, application support, infrastructure, and operations teams.
Aug. 4, 2015 07:00 AM EDT Reads: 229