Less wired Fedora!

I have to say that I have been busy: doing some RCP architecture, writing the VSIP for DevRiot, etc.

One of the things that I found less attractive about eclipse was the pda/device support. It is not as clean and streamlined as Visual Studio.

But the thing that kills me is that to add a custom icon to VS turned into a major hunt. I ended up using/modifying the one that is generated by the wizard. So it is puzzling that VS gets the pda/devices so right and messes up the custom bitmap icons.

But the no-way-jose :-} goes to Fedora Core. Last time I tried to use FC was in version 4. I decided to drop it because setting up the wireless was was turning into one nightmare of kernel modules, firmware, and plain cross-your-fingers.

So I thought, let's try FC 6, after all it has been two releases since and FC 7 is already in the works. I needed a clean Linux installation for the RCP thing.

Guess what? FC 6 was the same mess. I thought it could be me but their own forums are filled with the same story.

OpenSuse worked out of the box...

DevRiot .Net gets going, Beta for Eclipse almost available!!

3 People got their hands on DevRiot for Eclipse 3.X (Windows version) meanwhile I decided to get the .Net version a jolt.

Here is a snapshot of the GUI in the .Net environment. Pretty much the same as in Eclipse/Java. That's the idea: no new tricks to learn, no new tests to write. They are portable right off the start.

One down, two more to go...

The first install image of DevRiot is ready, some more sanity checks while I work on the other two and the documentation before it is ready for downloading!

DevRiot for Eclipse Beta 0 = 55.5 Kb

It is not bad, isn't it? To hold the plugin logic and the engine logic of a Unit/Gui testing tool, that is. Much of the footprint is the plugin/user interface logic. The engine is a reduced version.

A full fledged engine should not be much more than. It should fit in some devices, or it could be customized :-}

Well, next in line are the installers and documentation...

Micro pudding!!

As we get closer to packaging the beta, features become more usable. This sample video shows DevRiot running under J2ME CDC.

It is a GUI testing only video but the unit testing engine works fine as well. We previously mentioned that our approach to J2ME was coarse or brute force. In fact, we just run the Ide under J9 to force our plug-in to use.

As you will be able to see: it works and it is stable. It would be nice to have access to some emulators with Robot-like support but the main point is there.

Finally, Dynamic building update!!!

After a lot of trying on video formats and embedding, we have a another video update, we are pretty close to work on the installers. Things have smoothed over a lot.

We will create a couple of tests: one for the text field with a simple verification, and another for the button that is a little bit more complex. Here we will try to verify that after a click the field "AbstractMe"'s "ReturnMe" field has an arbitrary value.

Then, we will change projects to delete "ReturnMe" from Abstract.java and change back to run the suite again and witness that the tests were rebuilt automatically.

So if it was already an effortless task to create those tests, combined with the widget hound technology and the trimming/dynamic building, the net result is an extremely effective way to let people concentrate their time on more value added task.

I hope you enjoy it :-}

Please bear with me...

The internal build chain is pretty stable right now.

If a test case TC for type A in project P refers for some reason type B in project P1, any change in B is communicated to DevRiot and its internal build process (the trimmer to be exact checks any) updates TC with those changes.

We need to add a couple of buttons to the plugin so adding, running, and loading tests cases are separate tasks.

We are also changing the layout of the blog a little bit :-}

So far so good...

We are in the final test-debug stages. The process is going well with no surprises.

As mentioned before we are going to leave array, Virtual Hardware, and Swing support out of the beta.

We wanted to concentrate on the depth of the functionality rather than the breadth of the functionality, which will come later.

It will also be the common subset of native types and AWT widgets that exists between CDC and J2SE. The CDC testing has been pretty much brute force when more finesse is needed.

The "test-trimmer" and "widget-hound" features will be there and working.

Right now we are debating between letting the Apple version out without the GUI engine support or wait until the problem is fixed and include the GUI engine support...

The Widget Hound!!

The progress has not stopped around here. We have another little video to share meanwhile other features steady a little bit more.

This time we have a video of a feature called "Widget Hound". It is in WMV format and is less than 400K. The feature shows one of our approaches to test problematic GUIS.

In the video we will show a button-clicked method that every time is invoked, it changes position. In a capture-and-replay model this would break a lot of things, but we can rest assured that DevRiot can handle it.

The story line of the video is as follows, with the cursor already placed on the target method.

1) Launch debug session an click 3 times the button to show changing positions.

2) Launch DevRiot and a test case that generates the same 3 button clicks.

As you will be able to see, DevRiot can chase the running widget down and honor the clicks required by the test case. The maintenance cost of test suites drop dramatically with this approach.

The link to the video is here...

Working like a GPS! (Update)

The internal building process is stable, almost ready to face the public.

On the side I had been wiring/connecting a feature that makes the gui engine work like a GPS. I do not think I mentioned before.

It knows at all times where the widget-under-test is. So what's the benefit? The benefit is that the engine knows where to position the cursor at all times. It does not miss a click.

The benefits of skipping capture-and-replay ;-}

Back In Barcelona...

I had to come to Barcelona for 4 days. I am still in Barcelona, flying back tomorrow afternoon.

It had been almost 13 years since the last time I came. A lot of construction, and new luxury stores, etc. But still a pleasure to visit.

The Gothic district with its thousands of antiquaries, vintage stores, churches is worth roaming around. There is a small restaurant where Gaudí, Picasso, Dalí, Miró used to hang out. It is still open for business.

Casa Batlló, my favorite Gaudí building, is open to the public, there is a fee to pay though.

The Eclipse plug-in is almost there. The trimmer is a lot more stable. The internal building process plays well with the trimmer.

Just an simple and easy test retrieval interface is missing...

Running natively on Linux...

The following link will take you to another video of DevRiot running on Linux. Notice that by getting around the limitations of capture-and-replay, things are a lot simpler. For instance, there is no need to use Windows to test a Gui in Linux, or use JavaBeans for that matter.

The same applies to other devices like PDA, etc.

Well, here is the link

A small video sample ...

This is a small video of DevRiot Gui Engine running on Windows. The action is:

1. Clicking 6 times on a Button and verify that t == 7. This verification fails because the tool clicked 6 times only
2. Type 3 letters on a TextField and verify that t == 9. This verification succeeds.
3. Delete the logic handling the clicking on the button, and work on the Choice widget.
4. The "trimmer" kicks in, finds out that the first test is not useful anymore, and deletes it. The tool points out the obsolete is deleted
5. Select item 5 in the Choice widget and force a failure to show that the event actually happened.

The interesting things are: there is no need to capture-and-replay anything. And when the underlying code changes, the tool updates the suites automatically so there is no maintenance.

This is the link. It is in Windows Media format and a little bit over 1.5 Mb

Happy New Year!!

Still going...

Working on AWT menus. These were kind of tough cookies but finally got them under control...

It works!!

Well, the "constant gardener" works (the feature that keeps the test-base in sync with the source) but most importantly the GUI engine works like silk on Windows/Linux.

No capture-and-replace, no missed clicks just a clean way to trace the behavior of your logic: be it through the GUI, the unit tests, or both. No dependence on Windows, or Linux, or Mac.

I will try to have a little demo of the gardener running on Mac tomorrow. For a GUI testing demo I will wait a couple of days so more functionality is up-and-running.

Pre-Christmas gift!!

Well, the GUI testing engine (inside the eclipse plug-in) still does not work in Mac OS X. Despite upgrading to DP1. I guess the SWT/AWT compatibility has some more tweaking ahead.

On the brighter side, I am finishing wiring what I call "the gardener": code changes, method signatures change, methods are deleted. The gardener takes care of this by keeping the tests up to date with the real code.

I am still shooting to get a GUI engine up and running for Christmas :-}

1001 Tests...

Just to see where the engine started to show signs of effort, I decided to wire up some stress/load logic. I used a simple method that takes an int and returns it.

The rest is on the progress snapshots:

Enjoy :-}

The Proof is in the pudding...

This is a snapshot of DevRiot running on Eclipse 3.3M3 and Java 1.5. Note that the engine executed 100 tests and all of them failed. Despite the extra effort of reporting the failures, the little engine still needs a good set of brakes:-}

We are getting closer to the point where we can release this eclipse/java beta. We do want to move on to the VS/.Net beta because the performance gains here a orders of magnitude bigger than in Java.

Stay tuned...

Still rocking on java 5.0!!

We just got the first taste of DevRiot running on java 5.0 and we like it. The speed (ours) is still blazing fast.

There are a couple of bugs in java 5.0 that were affecting DevRiot and needed to address so they didn't hurt performance wise. That was done.

We will try to show how fast it goes before the weekend is over... :-}


Sorry for the unusual formatting. Blogger is not showing the formatting toolbar at this moment!

Busy Signal!

So I was working rewiring the GUI engine while it occured to me that the cell phone providers could have improved their support for the CDC platform and there were more emulators which support it (and java.awt.Robot which we do not need to run inside phones/pdas but it would nice to have)

The surprise is that they have improved their support of CDC but not so deeply. And from the answers, it seemed to be a weird question.

This is the type of things that I do not understand: with everything converging into everything, PDAs as powerful as older computers. Why are they waiting? Do they want to fall into the same trap the PC software fell?

I know of big blue companies that have teams of people tapping on PDAs to see if the app works as expected. After a while who is going to change that process and miss a deadline?

Ahh, the return of the keystone cops...