Sounds good. Now the question is "To what extend a software can be intelligent". Software these days, try to learn from patterns, user preferences, etc. But I wonder how a testing tool like agitator can do that! May be my imagination is not that broad :)

When we talk in terms of agitator, there are perhaps two important things that we can try to put effort in, to shorten that gap between the want and need.

1. "To show more useful observations".

Complexity and usefulness of observations itself is an interesting topic, since we are doing unit testing. Here question is 'what is the unit', just the class you test or a few other classes that are associated?. I have seen people defining unit from the method under testing to the group of all the classes participate in a call stack.

2. "To have more knowledgeable and intelligent auto factories to increase coverage".

Auto factories, which read the code, like a 'human do' and give more useful values so that coverage goes high. This will need the factory to be really aware of the API methods that are being called from your source code.

Now the problem is, we can make agitator, the Java standard API aware, but what do we do to the third party APIs.

There's more than need and want. There is "can use" and "thinks (s)he wants". We encounter a lot of these when doing specs. "thinks (s)he wants" comes in two flavours: flavour one is to codify existing processes (that could be improved). Flavour two is "I want a candy": request that are out of the toy box. "Can use" are functions users never asked for but empower them to achieve goals easer/faster/safer or reach goals they like but hadn't in view.
my 2c
;-) stw

Chidambaram -

Thanks for your comments. You're right on both counts - we need to improve observations based on "smart knowledge" of the code under test, as well as auto-factories that help improve coverage. With some new technology that we will be introducing in our 3.0 release you will see some of these "smarts" show up.

Related to the "needs and wants" topic though, I do believe that there's some learning that the Agitator can do based on how the user interacts with it. For a set of observations offered by the Agitator the user may generally convert a few of those to assertions. Agitator can learn from that, and when it needs to offer observations about other code that matches similar code patterns - it can know that the user prefers those "style" of observations - maybe prioritize those ahead of the rest of the list.

While that's only step 1 - I can see some significant work in making this way more smarter in learning from the user's interactions. Of course some of that work will only show over time, and is strictly under wraps at the moment.

Thanks again,

Ashish

Steve,

Lots and lots of traditional software has beed designed with a view that users don't know much, so of course, computers with their great processing capability can offer better solutions that they really "need". I don't subscribe to that view - not any more, not after seeing Google.

They've proved, I think, that learning intelligently from matching what the software thought the user "needs" (i.e. the initial search results) vs. what the user "wants" (i.e. the links that the user really clicks on) and then positioning the links that the user clicked on higher the next time - is the right way to go.

In the automated testing world - my take on the two concepts you introduce - with an example method:

public void addFoo(Foo element) {
if (element.isTypeOne()) {
typeOneList.add(element);
} else if (element.isTypeTwo()) {
typeTwoList.add(element);
}
}

thinks (s)he wants: This is what the user wants to test with. They want to pass in two parameters to verify that the code adds them properly - one of typeOne and the other of typeTwo. Fairly reasonable.
can use: The tool can quickly determine (as the agitator does), that other outcomes are possible in the method. - 1) NPE because element is null, 2) Nothing gets added because the element is neither typeOne or typeTwo, and 3) NPE if either list is empty.

The tool can offer all of these - thus supplementing the limited thought the user applied with what the compute power that the tool has access to. But, maybe, the element passed in can never be null - because the callers ensure that in all other code (is a contract that the domain offers). The tool ought to learn from the fact that the user doesn't care of the case where an NPE is triggered because the parameter is null.

Thanks for the two concepts - these make it easier even for me to think about needs and wants and how they map to our world.

Ashish

Terms of Use