|Jan 14, 2008||–||
Hoorah for XSLT!
It would be handy to have a report of all the unexpected exceptions that get thrown.
I've lost count of the number of times I've heard that. I've even said it myself a few times.
It seemed like it would be pretty easy to do using the
|Jan 3, 2008||–||
JUnit Factory is a Jolt Award Finalist!
First we generate over a million free JUnit tests and then we get nominated for a Jolt Award.
What a great end to the first year of JUnit Factory!
|Oct 15, 2007||–||
qu’ils mangent de la brioche
It is a curious fact that, if you say
Let them eat cake!
at an international gathering, the French-speaking people will have no idea what you are talking about. Even if you say it in French.
|Oct 13, 2007||–||
In Praise of Abstraction
A History of Build Systems
In my younger days, before I knew any better, many projects I worked on compiled and published their software manually.
One day, I discovered the discipline of daily builds and tools like make and my life got a whole lot better. Make gave us, in Elizabeth's handy phrase "a place to put things".more »
The Commitment Principle
Elizabeth Hendrickson is a tremendous facilitator and a canny manipulator.
In Influence: The Psychology of Persuasion, Robert Cialdini describes various techniques for making people do things that, if they were thinking clearly, they would otherwise not do because of lethargy, laziness, or because it would offend their better judgment.
One of those techniques is The Commitment Principle which was used on American POWs to great effect by the Chinese during the Korean War.
|Sep 6, 2007||–||
I have just generated unit tests for some code that would have taken months or years to do manually and I did it in under 30 minutes including registering on your server and waiting for the reply email.
That is truly awesome!"
Getting this kind of feedback is the fun part about having free (as in beer) software up on the web where anyone can try it out. In this case Nick had a great experience with JUnitFactory and let us know with a post to our forum.
|Jul 25, 2007||–||
Presentation tonight at BayXp
I might also show off the new crap4j tool that we have been working on lately.
|Jul 10, 2007||–||
CITCON Sydney Registration At 100!
I'm very excited that with two weeks remaining before the conference we've reached the 100 mark for registrations for CITCON Sydney. This is our fourth CITCON event but our first in Australia, so it is great to see so many people registered. We'll take up to 150 so if you're interested in attending, it's not too late to register. The conference will be July 27th and 28th, Friday night and then all day Saturday.
Btw, if you're not familiar with the Open Space conference format you might want to read this description. If you're still not sure if this format or event is for you, you might want to see what people have posted about past CITCONs on the web, or read the feedback from Dallas earlier this year.
|May 15, 2007||–||
Tomorrow night, I will be giving a talk at the Association of C and C++ Users in Silicon Valley entitled, "To Catch a Bug, You have to Think Like a Bug". This is a new and improved version of a talk I gave at SD West, so if you didn't get to go there, you get another opportunity to check it out. I hope to see some Agitator's there. You can find out more of the details at the ACCU's website.
|May 7, 2007||–||
I am going to be attending sessions at JavaOne this week, and would be happy to meet with any Agitators or testing enthusiasts at the conference, according to Sun's Event Connect tool, I can paste this code and you can link to me in their event tool to set up a meeting.
I also set up a topic proposal for the JavaCamp, unconference that is happening Tuesday and Wednesday nights, on Adding JUnit to the Java Platform.
Here's the blurb for anyone interested:
Many language platforms, like Ruby and Microsoft .NET ship with a unit testing framework as part of the platform. Why not include JUnit in the Java Platform, or at least include it in the JDK? Code quality is a constant sore spot for commercial applications, so it seems like making the tools that contribute to higher quality more widely available will encourage better code. While we're at it, lets put in a code coverage tool as well, so we can see how well we're testing. We already have some profiling and management tools built in, so this seems like a missing piece of the puzzle.
Scorecard for Bowling Scorer
JUnit Factory has a new feature - project dashboards - and I thought I'd try it out on my bowling code.more »
|May 4, 2007||–||
How much test coverage do you need? - The Testivus Answer
Referring to "The Way of Testivus" entry:
Here you go Morgan:
Early one morning, a programmer asked the great master:
“Don’t worry about coverage, just write some good tests.”
The programmer smiled, bowed, and left.
The great master pointed at a pot of boiling water and said:
“How many grains of rice should put in that pot?”
The programmer, looking puzzled, replied:
“How can I possibly tell you? It depends on how many people you need to feed, how hungry they are, what other food you are serving, how much rice you have available, and so on.”
“Exactly,” said the great master.
The second programmer smiled, bowed, and left.
Toward the end of the day, a third programmer came and asked the same question about code coverage.
“Eighty percent and no less!” Replied the master in a stern voice, pounding his fist on the table.
The third programmer smiled, bowed, and left.
After this last reply, a young apprentice approached the great master:
“Great master, today I overheard you answer the same question about code coverage with three different answers. Why?”
The great master stood up from his chair:
“Come get some fresh tea with me and let’s talk about it.”
After they filled their cups with smoking hot green tea, the great master began to answer:
“The first programmer is new and just getting started with testing. Right now he has a lot of code and no tests. He has a long way to go; focusing on code coverage at this time would be depressing and quite useless. He’s better off just getting used to writing and running some tests. He can worry about coverage later.”
“The second programmer, on the other hand, is quite experience both at programming and testing. When I replied by asking her how many grains of rice I should put in a pot, I helped her realize that the amount of testing necessary depends on a number of factors, and she knows those factors better than I do – it’s her code after all. There is no single, simple, answer, and she’s smart enough to handle the truth and work with that.”
“I see,” said the young apprentice, “but if there is no single simple answer, then why did you answer the third programmer ‘Eighty percent and no less’?”
The great master laughed so hard and loud that his belly, evidence that he drank more than just green tea, flopped up and down.
“The third programmer wants only simple answers – even when there are no simple answers … and then does not follow them anyway.”
The young apprentice and the grizzled great master finished drinking their tea in contemplative silence.
|May 2, 2007||–||
The Way of Testivus
In May 2006, an ill-prepared international expedition to the Himalayas lost its way. After two weeks of wondering around, hungry, thirsty, and smelling like inexperienced expeditioners who got lost for two weeks, they stumbled upon the entrance to an ancient cave.
Once inside, they saw a maze of ancient, and messy, cubicles. Each cubicle had a wooden desk, an ergonomically correct bamboo chair, a Dilbert™ calendar, and a strange computer-like mechanical device. In one corner of the office they found barrels of dark liquid which they later identified as early examples of carbonated and highly caffeinated drink and a ping-pong table. They realized that the cave was an ancient software start-up. The oldest one on record. Older even than Netscape.
Among the many things they discovered inside the cave was a note left by one of the programmers. The expedition’s guide, while not very good at guiding, knew how to read the ancient language and translated the note for them:
We have finished the release ahead of schedule – again. All the tests pass, so we are taking the rest of the week off. We are going sailing. Since it’s a team building exercise, we hope we can get reimbursed for it.
The explorers looked at each other in astonishment. Not only had they discovered the oldest software start-up in history, they had also discovered a team of programmers who, apparently, completed their code ahead of schedule ... on a regular basis!
What was the secret of these ancient programmers?
And what had happened to them?
The expeditioners searched each cubicle for clues and found two mysterious booklets. One of them was called "Learn To Sail In 30 Minutes”, which explained the fate of the programmers. You are holding in your hands a translation of the other booklet: “The Way of Testivus”.
Who wrote this mysterious booklet? What is Testivus? Only Google™ knows for sure.
Is the content of this text responsible for these ancient programmers being able to complete projects ahead of schedule?
We can’t be sure, but we believe that the amazing prowess of these programmers was probably due to a combination of the Testivus philosophy, and the consumption of large amounts of the dark caffeinated liquid found in the cave.
Read the booklet and draw your own conclusions.
Alberto Savoia, April 2007, Mountain View, Camore »
|Apr 6, 2007||–||
What Color Are My Tests?
I came across a nice quote from Ron Jeffries in answer to the eternal question about the color of the tests that result from TDD.more »
Triangular Honey from Triangular Bees
I hosted a JUnit Factory presentation a few days ago (you can watch it online if you missed it first time around) and spent a fair amount of time talking about the Triangle sample in the JUnit Factory demo.more »
|Apr 5, 2007||–||
Web Technology Cheat Sheets
There are a handful of web technologies that I use a lot. It's handy to have a cheat sheet around for when I can't remember whether it's switch-case or choose-when or if-test-else.
Here are a few that I use all the time:
Any more I should know about?
|Apr 2, 2007||–||
Good development depends on good testing
Sometimes an aphorism like “good development depends on good communication” doesn’t really sink in until it hits you upside the head. I experienced the reality behind this particular maxim recently when I expanded the number of developers on an open source project from one developer, myself, to two.
|Mar 22, 2007||–||
Coding in Public
I can code passably well and I am comfortable with public speaking - but there is something about combining the two that makes my brain just completely shut down.more »
|Mar 20, 2007||–||
Characterization Test Failures
For completeness, I run the characterization tests one last time. As you might expect, there are failures because the behavior of
I am impatient to be done now, so I'll try to get through the code for spares quite quickly so that I can review my findings.more »
How Are Those Characterization Tests?
Someone asked me how the characterization tests fared after such an extensive change. After all, I added new methods, new behavior to existing methods and I refactored extensively.more »
How Are Those Acceptance Tests?
With the code for strikes written, it's time to run the acceptance tests to see if they agree that we are done.more »
SD West Talk: To Catch a Bug, You Have to Think Like a Bug
Tomorrow morning, I'll be giving a talk at SD West 2007 on developer testing. It is a a very opinionated look at how to test your code. It should be fun and useful. If any Agitators or other test afficionados are going to SD West, it would be great to see you at the talk, or afterwards as well.
Here are the details:
According to the rules:
2.1.3 A strike is made when a full setup of pins is knocked down with the first delivery in a frame.more »
|Mar 19, 2007||–||
Characterization Tests Revisited
Before I move on to the next story, I want to revisit those tests and make sure we have not introduced any regressions.more »
How does the Score Sheet Look?
Before I move on to spares and strikes, it would be nice to see how the score sheet looks. In an earlier post, I claimed that one of the reasons for integrating the UI early is to make sure the domain model will satisfy the requirements of the user interface. Let's see if it does.more »
|Mar 16, 2007||–||
Are We There Yet?
My last post ended with this bold assertion:
If I am not mistaken, I have written enough code to pass the acceptance tests for this story.more »
|Mar 15, 2007||–||
First Design Your Data Structure
It's at about this stage of the bowling example that people usually leap into a discussion about the appropriate data structure to store the rolls and the APIs for exposing the results.more »
In which we design the score card
In the previous installment, I wrote the code that implements rule 2.1.1. For rule 2.1.2, I finally start to add up some scores and show them in the score card.more »
|Mar 12, 2007||–||
Testing Around the Edges
It's an interesting word, 'test'. It can mean so many things. Before XP came along it used to mean
find out whether something works correctlymore »
A game of tenpins consists of ten frames
In my previous blog entry, I posted a set of acceptance tests for the first few stories. It's time to start writing the code to pass those tests. I prefer to discover the design through TDD rather than code directly to the customer-facing tests.more »
|Mar 9, 2007||–||
Acceptance Test for Bowling Scorer
I have often written acceptance tests for code that has not yet been written (in fact, I wrote an article about it) but I have never written tests that will work with any number of implementations, each with their own architecture. I don't even know how to go about it, but that never stopped me before...more »
Bowling for Objects
"scoring a game of bowling" is probably the most common application used when demoing TDD. It's so commonly known among the JUnit crowd that I chose one of Bob Martin's efforts as a demo for JUnit Factory.
The topic comes up about once a year on the TDD mailing list and it just came up again. By an odd coincidence, we just celebrated the completion of a new release of AgitarOne with a trip to Homestead Lanes, so I am all fired up about bowling despite my dismal performance (there was beer involved).more »
|Mar 8, 2007||–||
EclipseCon and Ward Cunningham
For me today was my best day so far at an EclipseCon, but as usual for a conference (except CITCON!) the most interesting stuff was what happened outside the talks...more »
|Mar 6, 2007||–||
CITCON Dallas Registration Open
We are proud to announce that registration is now open for the next Continuous Integration and Testing Conference, CITCON Dallas on April 27th & 28th. Space is limited to the first 100 registrants and attendance is free. Registration is on-line and while it is open until April 13th we do expect to fill all the available slots, so sign-up soon to reserve your spot.
The conference will be following the same Open Spaces (or unconference) format as the 2006 CITCON in Chicago and London. These prior CITCON drew enthusiastic practitioners at all levels of experience, all looking to share what they knew and to learn what they could. We're looking for more of the same in Dallas.
Please help spread the word about CITCON and we look forward to seeing you there!
EclipseCon Panel on Developer Testing
If you're at EclipseCon this week you might be interested in stopping by the panel Making Unit Testing Part of Your Development Process: How to Get Your Team to Do It. I'll be there as a panel member... but it should be a good panel anyway. ;-)
|Jan 26, 2007||–||
Mocks Aren't Stubs by Fowler
Mocks Aren't Stubs by Martin Fowler, is a very comprehensive look at two pairs of issues in testing: state-based verification vs behavior verification, and classical TDD vs Mockist TDD.more »
|Jan 25, 2007||–||
Floyd's Turing Lecture on Paradigms in Software
In light of the recent conversations about the adoption of developer testing on the junit list and Artima, this Turing Award lecture by Robert Floyd seems particularly appropriate. There's a particularly good quote where he is discussing a quote from Thomas Kuhn in "The Structure of Scientific Revolutions."
"Again from Kuhn:I suspect a large number of the adoption problems for developer testing are in organizations where the old boy at the helm is clinging to an outmoded paradigm of software development. Perhaps those guys would listen to Floyd -- (Robert, not Pink.)"The older schools gradually disappear. In part their disappearance is caused by their members’ conversion to the new paradigm. But there are always some men who cling to one or another of the older views, and they are simply read out of the profession, which thereafter ignores their work."In computing, there is no mechanism for reading such men out of the profession. I suspect they mainly become managers of software development. "
|Sep 18, 2006||–||
Final Days to Register for CITCON London 2006
CITCON London registration will be closing this week, it is just hard to know if we will hit the deadline of Friday September 22nd or the cap of 120 people first! At last count we have 85 people signed up and if history is a guide the remaining spots will go fast.
Given the open spaces format it is impossible to predict what the exact session topics will be but a sampling of the topics (and notes) from the CITCON Chicago event from earlier this year is available on the wiki. Also available are some photos, feedback, links to related blog entries and more... More than enough to be convinced that you should sign up today!
|Aug 24, 2006||–||
Build Failures Policy
I just wrote a page on our internal wiki with our policy for dealing with build failures. We thought others might find it interesting so I am sharing it here (the links will be broken for obvious reasons).
If the build fails, fix it.more »
|Aug 21, 2006||–||
Webinar: Test-Driven Development in J2EE, with J.B. Rainsberger
In early August J.B. Rainsberger gave a webinar on TDD for J2EE:
Test-Driven Development is often introduced through simple examples, but many developers would rather dive into the deep end. This free webinar is for those people. J. B. Rainsberger, author of "JUnit Recipes," will show you architecture and design strategies to make it easier to "test-drive" J2EE components. You'll learn how to build a J2EE application while following the cardinal rule of Test-Driven Development: Never write a line of production code unless somewhere, a test has failed.
|Aug 11, 2006||–||
Failing tests shouldn't always break the build
There are many reasons why you might not want to fix a failing test right away. Maybe it's an acceptance test for a feature that you haven't written yet. Maybe it's a regression that it's just not practical to fix right now.
But what to do with that failing test?more »
Old metrics never die
If a little bit of feedback is good, a lot would be even better, right?
Is there such a thing as too much feedback?
XP doctrine says that you should stop tracking metrics once they have served their purpose. You should only have 3 or four "Things To Focus On". There's a reason for that.more »
|Jul 21, 2006||–||
Dos Equis Driven Design is Not About Beer
It is critical to remember that Dos Equis Driven Design (XXD) is not about the beer. (I'm not saying there was no beer involved, but that isn't the point...)
|Jul 14, 2006||–||
Put Your CC config in Version Control
I got fed up with updating the 20 step instructions on our wiki for configuring a new cruise control machine so I wrote a script and checked it in to CVS. Obvious really.more »
|Jul 6, 2006||–||
"The lesson of the bloat trochar and the rulebook"
Brian Marick is at it again with a must-read post on the Agile Testing mailing list titled "The lesson of the bloat trochar and the rulebook", but unlike all the previous posts or messages I've directed my gentle readers to view this one is entirely unquotable. To me it is a single piece, to be consumed entire or not at all. The closest I can come to providing the flavor is the embarrassing situation of quoting the post quoting Whitehead:
It's like what Whitehead said about notation: "By relieving the brain of all unnecessary work, a good notation sets it free to concentrate on more advanced problems, and in effect increases the mental power of the race."... but that doesn't do it justice. Maybe better is to quote Kevin's reaction:
Outstanding post, Brian. I always wondered what the little star was for in GMail. Now I know. Your post has a little gold one next to it.So... go read it already, 'k?
|Apr 21, 2006||–||
Webinar: What to Do if Your Code Has Few, If Any Tests?
Next week Agitar is hosting Ted Husted of the Struts development team (and iBATIS and MyFaces and Jakarta-Commons) in a webinar on What to Do if Your Code Has Few, If Any Tests?. I'm curious to hear what Ted has to say but his talk illustrates the kind of trade-off that exist as our company grows. One the one hand we can having interesting speakers and topics like this, but on the otherhand we're now scheduling the webinars for a global audience, so the scheduled times (7 am and 5 pm PDT) probably work better in just about every other timezone than this one. (</whine>)
|Apr 13, 2006||–||
Test vs Spec or ForAll vs ThereExists
Brian Marick says that tests are not specifications but I believe there is a more fundamental distinction.
|Feb 22, 2006||–||
A Recipe For Making Developers Write Tests
This is the only thing that has ever worked for me.
1. Test your own code as well as you can
It won't be long until everyone will want to have tests.
Most developers will not make the investment until they have seen proven returns. The management challenge is to find the early adopter with the courage and vision to take that first step.
|Feb 18, 2006||–||Software Development Learning from the Spacecraft Business Glen Alleman was reading Development of the Space Shuttle and got to asking "is there anything we can learn from the spacecraft business that is applicable to software development?" (via Lasse Koskela)|
|Dec 1, 2005||–||Shameless Plugs|
|Nov 5, 2005||–||
Inspired by A Thought Inspired by the CSS2 Specification
Brian Marick was inspired by the CSS2 spec to note that:
That suggests that a specification should not be written to a consistent level of precision. Precision is needed only where disputes have already occurred or are likely.Translating that into developer testing I immediately thought "That suggests that unit tests should not be written to a consisten level of precision. Precision is needed only where disputes (or confusion or bugs) have already occurred or are likely."
|Oct 5, 2005||–||
Cheat Sheet for Interview Candidates
Just to make it easy for any potential candidates out there, here's my whole interview question for the J2EE position.
I want you to build a Hello World application in J2EE. I want you to do the simplest thing that can possibly work.more »
Tips for being a good interviewee
1. If you are interviewing for a company that makes tools for developer testing you should probably know something about developer testing.more »
|Sep 27, 2005||–||Stop: The Bar is Green I think it was repeated hints from Robert Watkins that finally got to me. I took the time to install David Saff Continuous Testing plug-in for Eclipse and I'll tell you now that I never want to be without it again, but not for the reasons I've heard from other people. more »|
|Aug 24, 2005||–||
Rules for Unit Tests
Michael Feathers gave this excellent set of rules for unit tests on the XP mailing list:
I have these rules that I use for unit tests, primarily because I encounter so many teams that start writing end to end tests, call them unit tests, and give up because "testing takes too long". To me, a test is not a unit test if:
|Jun 15, 2005||–||Open Quality Data in the Annual Report? Kent Beck told me that he showed the Agitar Management Dashboards at a public company where he was consulting about software development process. Then he asked them what the impact would be on their software development organization if they had to track such data for their key software applications, and then publish it on their public website. And if they also had to refer to the data in their annual report and explain any changes in trends. more »|
|May 26, 2005||–||
InfoWorld's Jon Udell Interviewed Alberto Savoia
On Thursday May 26 Jon Udell interviewed Alberto Savoia. Alberto had just been selected by InfoWorld as one of the 25 Top CTO's in the US in 2005. Jon asks Alberto about his vision for Agitator and Alberto demos Agitator extensively.
You can see the replay now if you don't mind registering. If you do, come back in a few days and we'll point you to an unguarded version.
|Apr 18, 2005||–||Sustaining Legacy Code Last month I visited some customers and prospects in India. One of them was an outsourced provider of software engineering services. Sure enough, some projects they get are to maintain and sustain an existing body of code. "So how does Agitator help?" they ask. more »|
|Apr 11, 2005||–||The Monty Hall Problem The Monty Hall problem comes up every now and again - it's currently being discussed on the XP mailing list. It's a great problem. The description of the problem is well discussed on the web, so I won't repeat it here. more »|
|Feb 17, 2005||–||Needs and Wants Recently while chatting with Alberto the phrase "what the user needs and wants" came up in our talk. That got me thinking a bit, what's the difference. It struck me finally that, that's the core difference between a market success or not. more »|
|Feb 9, 2005||–||Failures in Unit Testing This morning on the Agile Testing mailing list someone pointed out Mike Clark's blog entry "Failures in Unit Testing". more »|
|Feb 6, 2005||–||The Developer Testing Burden I started at Agitar (Engineering Management) in August - but have been associated with the team at Agitar for the last several years. In my past life at SunTest (Sun Labs), I was responsible for creating several Java testing technologies (primarily focused towards load testing) - and being a geek at heart - the "toughness" of the testing problem has always kept me charged up about solving it. more »|
|Jan 31, 2005||–||Blind Spots, Frequent Testing, and Software Agitation Andrew Binstock's column Integration Watch in Software Development Times of January 15, 2005, reflects on the difficulty of writing developer tests for cases that the developer does not anticipate. more »|
|Jan 27, 2005||–||A Bad Day With Continuous Integration Yesterday we had a problem. Just before 6 pm someone checked in some changes that broke our unit tests... more »|
|Jan 11, 2005||–||The Feng Shui of Developer Seating Over the past year we've had several different variations on our seating, with the common theme of an open workspace. Originally there was an 8 desk circle, which in time was supplimented with some cube space. Then we broke off a separate team for The XPeriment and added a separate 'pod' of 4 tables. With several minor variations all these seating options worked well and I felt pretty safe thumbing my nose at those people who advocate offices with doors that close as the best environment for development teams. more »|
|Dec 13, 2004||–||
Kent Beck, Google and Expert Panel videos from Developer Testing Forum
Agitar has posted the videos from the November 17th Developer Testing Forum--they are now online at www.unikron.com/agitar1/. Presentations include Kent Beck, Sriram Sankar (Google), and an Expert Panel (Russell Gold, Oracle; Rob Mee, Pivotal; Sri Muthu, Wells Fargo; David Vydra, Testdriven.com).
|Dec 9, 2004||–||TDD and Agitation I have been doing Test Driven Development (TDD) for about four years now and agitating for a little less (it's my second anniversary as an agitator today) and I have thought a lot about how to marry the two testing styles. A discussion on the TDD mailing list today (http://groups.yahoo.com/group/testdrivendevelopment/) finally gave me a name for what I have been doing for a while. The discussion centered around the relative merits of TDD versus Design by Contract (DbC) and a surprising - surprising to me anyway - number of people said that two are complementary and that they do both. That's exactly what I have been doing without realizing it. more »|
|Sep 13, 2004||–||Creating a Value Type for Validation (revisited) Earlier in the year I wrote about introducing a wrapper type to encapsulate the validation of a value that is essentially just a string (see Fight Complexity with Complexity). I just ran into the flip-side of this - the anti-pattern if you like - and I felt compelled to rant about it. more »|
|Jul 16, 2004||–||Testing HTML Pages I started this article intending to talk about a technique we developed for testing Velocity templates but realized that there was enough background material for a separate article on testing html. So, this entry describes how we developed a harness for checking the output from the Management Dashboard. A second entry will talk about how we adapted the harness for testing Velocity templates. more »|
|Mar 8, 2004||–||Fight Complexity with Complexity We were using method and class and package names as keys to the various data structures that store test results and coverage data. Agitator told us that if you pass the string "123%%^*abc" to a method that expects a class name, it throws an IllegalArgumentException. "Well, duh!" we said and marked it expected. We added a factory to generate a variety of good and bad class names and got on with the task at hand. more »|
|Jan 26, 2004||–||Violent Agreement In his blog Patrick Logan makes a very good point that "we have to make a distinction about what kinds of tests we're writing and what kinds of tests we want to automate." more »|
|Jan 16, 2004||–||Why Is Software So Hard To Test? Start a conversation with any developer about unit testing and, before long, he'll tell you that automated testing is a fine thing in principle but that his code is too hard to test because .... more »|
|–||Continuous Integration, Continuous Agitation With automated tests, like money in the bank, the joy should be the using more than the having. But unlike money, you can use the same test again and again, and we've found that being a spendthrift with our cpu cycles is the best way to get the feedback we need to drive our product quality. more »|
|Jan 8, 2004||–||Project OPLA, or: How We Stopped Worrying and Learned to Love Agitator™ One of the key moments in the creation of any tool is when you can start "eating your own dog food". After many months of work, Agitar reached that milestone with our own self-agitation project we call OPLA. Today OPLA is an integral part of how we develop Agitator. more »|