Emulators

There will be another UI element in DevRiot command set. A combo box that will allow the user which emulators are available to use given the current project. If a project is a smartphone one, then only smartphone SDK emulators will populate the combo box.

Moving to VS 2008

Adding support to the different devices that exist in the Compact and Micro Frameworks is forcing us to move development to VS 2008 from VS 2005 it seems a doable task in a short period of time :-}

Starting on .Net Compact and Micro Frameworks!

This afternoon we started the wiring of DevRiot to the .Net Compact and Micro Framework emulators.

Some considerations:

• The execution speed will not be as good as DevRiot is on the Desktop Framework. Those are resource constrained frameworks.
• There will be an smaller amount of threads available to the Load & Stress Engine.
• The maximum number of tests will not be affected.

Available!

We are happy to announce that DevRiot for Visual Studio 200X(Beta) is available for downloading at:

http://efekctive.com/beta_public/

The documentation can be found at:

http://efekctive.com/docs/

Don't forget you will need a working email address, a working internet connection, and a SQL Server instance available to install and use DevRiot (the email address is required during setup only)

We hope you find it useful and worth the time to try it! If you have any questions please contact us at this address: beta at efekctive dot com.

Just waiting...

Everything is just waiting for a final delivery hurdle to clear and the beta will be available....

Almost there...

The obfuscator has been selected. Building + obfuscating + packaging + installing + monkey testing. In short, making sure it works before actually buying it...

Documented

The documentation is "done". It needs editing to polish my written "spanglish". The setup needs changing to avoid a random identification failure while installing a final round of "monkey testing" and beta should be ready to go!

Wiking!!

For the last few days we have been putting together a simple documentation for this beta. It can be found at: http://www dot efekctive dot com/docs.

Mild and off-target...

After a harmless hack attempt at the wrong site, it was suggested by my isp to harden the site logic. We did so it is robust enough to avoid the easy gotchas, we believe.

Now off to put a little documentation together with the previous images and posts and it should be ready for the public to break...

Done.

The generics engine, and the engine in general, is stable enough for somebody else to break it. The install/deploy phase begins. A video with the full shebang of features will come in a few...

One Bug Down...

DevRiot's generics compiler has a couple of bugs that make it behave different from .Net's standard behavior. One is already down. The other should come down soon and deployment start...

FormMinder!

Some messy code on our behalf renders DevRiot's GUI unusable. And it looks random so far. Working on it...

DevRiot Beta is wating for deployment...

We fixed the nested generics problems. It looks good enough to let people really find its problems.

This leaves DevRiot beta ready to be used once the deployer method is ready. Will be off the grid on a 2-week friends & family & surfing trip. A break is called for.

1,600 T

I have been trying to squeeze more than 1,600 concurrent threads out the engine without changing any settings. No luck. Obviously, it will need a closer, slower look and better tools. Still 1,600 is a number that can be useful, specially when one invests 30 seconds or less to create, use, and harvest.

Measuring up...

The L&S engine is working just fine. Some changes were made to allow users to measure on a per-thread basis the execution times. Like the Time-To-Live concept: if a method takes more than X ticks, a failure is reported.

Me too!!

There will be no public beta for DevRiot .Net. Just access to the people who kindly signed up to try it out.

So for those me-too with a laundry list of me-too features, stop poking around!

Meet the Press...

In what could be a series of fortunate events, I missed a plane on Jan 1st. So instead of flying, I was working when CIO Senior Editor was gathering opinions about another QA mess. The last one I knew of was from MySQL. This new one was from MS.

So I decided to chip in my two cents since not many people was supposed to be working, the published article is here.

ISB

I hope it is useful!!!

The octopuss

Recompiling load & stress tests is taking some bug-fixing effort. Working on it :-}

To Shake!

The weekend was busy as any impending across-the-Atlantic move would demand but I managed to download Chrome (I have been using Firefox for years) and poked around the web.

I tried to run the technorati searches that we appear on but it didn't work. It may be a matter of sgining-in, the reading was interesting nevertheless.

Some of the posts were pro unit test other against, Agitar, Agile, etc.

A blogger explained that Agile is an incremental methodology where the developer decides what to work on next. A couple of them stated in other posts that a lot of their collegues just don't write unit-tests.

It is not surprising: as soon as the decision of what to work on is made by the over-pressured project manager, something's got to give.

Agitar's demise may be a consequence of the previous, but it also missed some crucial requirements: it just worked unit tests, the underlying framework was somewhat limited. It also solved just part of a customer problem: product quality. By only adding a lock statement the whole thing lost compass.

BTW, Chrome seems very useful...

Recompile The Move...

Ok it's hard to move across the ocean again and fix bugs but we have managed to fix some areas that were choking while recompiling: abstract classes + interfaces.

Still no departure date.

Params, Threads, Generics This is another progress demo. It involves: dynamically allocating params, genereics, threads, and switching between classes. Everything is handled transparently and effortlessly to the user. With such a small learning curve, ease of use, and blasting speeds the testing "Total Costs of Ownership" should be extremely low while attaining effectiveness never seen before. Enjoy your Sunday morning...

Smooth...

After cleaning up some bugs, a task that is still going, here is another sampler: a 500 thread session, with generics included, ran twice under 3 minutes from scratch.

That is generics type, tests + threads creation, and run. Everything completely synchronized.

General Dynamic Fixtures

This is the first work-in-progress report in a while. It shows how DevRiot dynamically generates, stores, and retrieves tests between sessions.

The "fixtures" are handled dynamically. We can mix and match the generics parameter types on-the-fly, keeping the engineers effort easy, flexible, and quick. Extremely quick.

Very few tools on the market can offer such a low Cost of Ownership, in the short or long run :-}

Enjoy...

Summer Blues Report...

I must admit that moving suites/tests from storage to binary form has been a challenge. It has become more difficult than DevRiot for Java because it has more features to take care of.

Generics Generation has posed its own set of binarization challenges.

But still snailing away...

Still working out the bugs...

...inside the generics engine to recompile the tests from storage. Not being able to ask questions makes the work slow down a lot.

Will have another demo soon.

The Referencer

Is still working on fixing bugs. The logic to implement new/old method matching is uncovering a lot of bugs. Not as close to beta as I thought or would like...

Generating Generics...

Stuck here. Trying to combine serialization/de-serialization of suites with generics and not generics is proving to have several traps...

Less than two minutes...

We have been tweaking around the serializer (getting rid of duplicate IO work) and writing, storing 100,000 tests takes less than 2 minutes. The development costs aren't why they used to be...

A more realistic approach to this feature can be: there is a method that takes a matrix and returns a modified version of it. Given the nature of matrices, a user could create a "base" test batch with a baseline matrix then modify the individual matrices with minimum effort.

Going academic!!!

It is always encouraging to see that not only businesses find the white paper useful. A lot of universities, institutes of technology from all over the world have been downloading the white paper (even for course work)

Even a national police from South America :-?

Well, the serialization server is moving forward nicely, although the weekend was lost with a clogged up laptop. It has been deleting *.tst file for the last 48 hours...

Storage...

I must have to say that developing code to serialize large number of objects can be quite time consuming.

My laptop seems to handle 100,000 or less files quite well. When the number jumps to 1,000,000, it becomes messy molasses to continue working.

Will keep you posted...

Gluttony...

Being able to handle large number of tests (5,000,000 in my dev machine, but it could be higher) is that serialization of suites becomes a little bit harder.

Well, that is what I am working on now...

5,000,000

After tweaking some generation logic to economize the memory consumption, DevRiot reached the 5 million tests mark in less than 34 seconds.

Sounds fast, isn't it? Now, really going back to suite serialization...

I tripled THAT...

1,500,000 in less than ten seconds. Back to Suite serialization...

500,000 and counting...

The Suite serialization is slowly starting. I am polishing some performance features.

But I wanted share with the latest readers some of the brute-force finesse of the tool:

500,000 tests, no coding, no wasted time. Enjoy.

It does not register

Well after having a question/post mysteriously disappear from the VSX forum, which is a first, I decided not to wait more on that.

Two registry entries will allow the user to gauge according their HW configuration what the max number of user/threads DevRiot can handle and the emergency TTL (when all current users/threads are harvested to avoid hosing down the box)

To be a product that has a really small exposure, there a lot of big copycats :-}

Time To Change...

Well after fiddling around with the load/stress engine + 1,600 threads/users for a while, I think it makes more sense to let users set the TTL per test.

It is easier for the user to set it according to their knowledge of the code than use any predefined formula.

It also becomes part of the verification data of the test which should be useful.

Thread Quartet in K reverse...

The following demo shows a Load/Stress session on a object using four of its methods X 400 threads/users (1600 total).

In addition, there is the Assertion, Out-Of-Scope, etc, in a codeless, easy-to-use, low-skills-needed sort of way.

It is a little bit longer than the previous ones but worth watching (it has been edited to avoid the initial setup of the threadpool) :-}

1,500 Threads in action

Well , we wanted to try a higher number on our load/stress engine. So, we tried 1,500. Watch and enjoy the execution times after the initial run (when all the setup occurs).

58 Seconds...

That is how long it takes to create, launch, execute, synchronize, and verify a load/stress session with DevRiot. Check it out for yourself...

Why wouldn't you want that level of efficiency in your SDLC? :-}

Visual Threading!!

This is another progress demo with assertions, out-of-scope verifications, multiple threads were involved in a series of tests. Not a single line of code was written.

Try to achieve the same with other technology: Microsoft's, etc. See how much time it takes you to achieve the same. Then check how much more time it takes to get the results back.

How do you want to spend your time and budget? :-}

VUT Threads...

This is almost identical to the previous demo but with the difference that the Load/Stress testing engine is hooked up.

Note that the video follows the same script as the previous one, so no PrivateObject API or coding or scripting. Even the thread creation, execution, and harvest.

The other difference is that we intentionally tried to add a test without pre-compiling a parameter so the tool could complain :-] Three threads are created and used against the method under test.

Automation?

We are currently working on the ContextMenu manager. It should be a breeze since the Generics support actually meant a major addition of functionality.

GUI support should come soon too, its major piece of functionality is ready to wire.

Which lead me to look at the Automation library that MS has on .Net 3.5-VS 2008. It is not a surprise , and not a particularly interesting competitor.

First is stuck in PC land. None of the major classes are supported by the Compact Framework.

Second, it is another hard to digest class/method behemoth.

I guess they are not competing on usability and product definition/differentiation...

Compare me if you can...

These two are a couple of progress snapshots from the Generics Engine.

To show the flexibility and ease-of-use of DevRiot's Visual Unit Testing(tm) technology here we have a generic method that takes 3 generic parameters. Each one of them is a bound generic type A made of an array of bound generic type B. Type B is made of an array int.

Just a few clicks away. No Source code...

That ugly description turns into an easy to use tree widget:

General Complexity

The Generics Generator is pretty smooth now:

This is an snapshot of a that involves: generic method, out parameter, multidimensional arrays, out of scope data (PrivateObject in VS parlance).

And it is the same as if it a method that takes and returns an integer. The user just spends time on what it matters most: substance and not boiler plate noise.

None of the competitors can achieve such a level of usability and ease-of-use. Let alone the execution speeds. We are pretty close to wire up the GUI testing engine...

GG:

Well, shortcuts do not always cut or are short. We need to frame a Generics Generator that makes the trick in the long run and not a longcut that comes to bit us later when it is hard to touch the innards

This is where we are now...

Anything VUT...

Visual Unit Testing, this is the acronym that best describes the visual nature of DevRiot's user experience. It also applies to the GUI testing engine but there are more salient features that describe DevRiot's GUI testing engine: device independence and ditching the capture-and-replay paradigm.

Back to ironing out some bad bugs in the generics generator logic...

Params Row...

The thingy handling the params modifier is pretty stable now. There is a scenario where it NPE's but I am about to fix it. It is a little bit convoluted because it involves also the dynamic-scoping of parameters.

Next will be databases (offering a clean way for the user to test databases). Collections/Data structures will be partially supported for the beta. The GUI testing engine work will begin soon, hello .Net Compact we are going your way!!

DevRiot for Eclipse NOT available

Since last saturday, we have seen several failed attempts to dowload the beta version of DevRiot for Eclipse. It is not available until further notice. I guess the links do not have the same note as the html page. We apologize even though is beyond our control.

We suggest waiting until the improvements and features developed in the .Net version spill over to the Java version. You can register for both here.

Thanks for your patience.

For Completeness' sake...

I just compared DevRiot for .Net against Nunit 2.4.3. DevRiot is 2,400+ times faster than Nunit.

And it includes GUI and Load/Stress testing, try to find those inside Visual Studio or Nunit :-}

The waves are just getting started. I'll try a two session day tomorrow :-}

The Fog of Fall...

Well after the dry and brown fall we have had so far (Galicia is like Seattle/Washington, rainy and green all year long) Some fog and rain has arrived last week, and with them some nice fall swells which I plan to take advantage.

As I mentioned in an earlier post, I managed to compare DevRiot .Net with Visual Studio 2008 Tools.

The performance of DevRiot .Net is really good, given we do not have access to any of the internals: on the low end DevRiot .Net is between 800-900 times faster than Visual Studio tools.

The time it takes Visual Studio to process the first test, DevRiot is close to 1,000. But if we reach the 100,000 tests, DevRiot outperforms Visual Studio tools nearly twice that figure.

As any sensible management guy would tell you: why waste time writing code to get slower?

I will be working on the GUI testing engine, particularly support for the .Net Compact Framework.

And, I will try to catch some waves. Enjoy...

Tick, Tick, Tick, Tick, Tick...

This has been a really productive week. I accomplished to run DevRiot for .Net under the new architecture for the first time.

Let's say I will hold off until early next week to announce the performance improvements...

Simple Update...

Well, just working in the guts of the engine now. Where the fireworks occur. No snapshots to show but really entertaining to fiddle with.

Still undecided of how to cache things for the compact framework devices but making great progress.

Context Adjustments...

Some times it is amazing where pointers to adjust features can come from.

And I have to say that MS seems to be on the ball supporting the extensibility community (not related to previous line)

Anyways, DevRiot's UI has changed a little bit to make things easier on inherited methods,fine tunning runs and having multiple instances of VS up.

We wanted to get this stable before get into the gui testing engine for .Net compact and device integration. It is going to be fun :-}

P.S. The second "Run Current Tests" really runs the whole suite.

Tell me what posts one is reading...

And I will tell you what one's marketing plan missed :-}

Well, Leopard came out. It may have solved some of the SWT/AWT problems that DevRiot was experiencing on OS X. I need to get back to it later. Some people got really upset that Java 6 is not included or better java support on OS X is demanded.

It is understandable but things should get less emotional.

After all, not long ago Apple was in the doldrums. It certainly came back but it is behind every big player in the Java world. And it is not going to let IBM or Sun have a piece of the Apple pie out of goodwill.

There are a lot more Java/IBM developers than OS X developers. That in itself is a major threat.

Well, I am going back to .Net and make sure DevRiot does not choke when several instances of Visual Studio are up and running...

Context it!!

We have done a little backtracking with regards of the original way we planned to handle assertions. Interfaces and abstract classes will be handled the same way: context strip.

Here is goes another snapshot of the work-in-progress:

What an eye sore!! (102,796)

Well, I finally managed to download all the components for Visual Studio 2008. It was long a process because of the size of the archives involved. Regardless, I have to say that the process was smooth.

Now to the substance, comparing DevRiot and the test tools of VS 2008.

I started with the basic: take an int and return it.

Nothing else fancier where DevRiot has advantage over VS: gui testing (on PC and devices, on and off screen), dynamic array/data structure manipulation, dynamic build test tress, built-in load and stress testing, etc :-}

It is an eye sore: test projects, test types, test attributes, test contexts, asserts, clicks, clacks to get to the point of to modify the test source to add the only thing that is of interest to the user: desired input and expected output. That is all a user needs. If the user needs to add a second test: repeat the process :-}

The thing is dog slow. It took (on average) 102,796 times more ticks than DevRiot. Granting that I was using Virtual PC but the times I am using for DevRiot are from 4 years ago on much slower machine than the current one I own.

If we assume a 50 times handicap (meaning that a 5000% improvement) DevRiot is still around 2000 times faster.

No wonder the execution time report is not the default one.

I tried to mess MS tool with changing return types, it choked like a child. Then I tried exceptions or even setting scenarios. It would have required getting into coding, api, etc..

I do not think they have clear concept of what automation means.

So, bottom line: why spend more time using MS QA infrastructure if it is not going to yield faster development cycles?

The pricing structure and road map discussion, I will leave for other post.

Slipping Cookie...

As I wait for Visual Studio 2008 to download/compare its QA features against DevRiot (it takes a bit to download everything) and work on the context menus of DevRiot, there was this funny piece of news:

Hamilton admitted that his car stalled because he pressed the reset button by mistake.

Go figure, which kind of strategic thinking went through Dennis' head. Back to work...

Progress in General:

Here we have a couple of the .Net tool working with generics:

It is funny how monitoring works. A big portion of the traffic drops, and then hits on the whitepapers and J2ME topics surge. And then a big portion of the traffic is back.

To open source or not to open source...

I was im'ing with a good friend from Austin, catching up after a few months off.

She was somewhere on the west coast on a business trip. She mentioned that I should open source the whole thing. She is working on SOA a lot lately. The whole thing is hard to test. So buddy, open source it!

I have toyed with the idea before, and yes SOA is hard to test. But then one looks into WPF and the ball-and-chain (to paraphrase Jobs) Microsoft is putting on these widgets just to make sure they are testable and one realizes that before testing SOA we would need to make sure that simplest things work.

BTW, I am been trying to figure out for several days why would anybody want to take that approach to no avail.

Off-topic:

Well, one thing led to the next. It started with using .Net 3.0 and the GUI testing engine, and ended up in: "we need to make sure that the off-screen engine works".

The off-screen engine is a feature of the GUI testing engine that allows these type of tests to run at speeds close to that of the unit test engine. The main goal is to increase the throughput of the process without losing accuracy.

BTW, it works...

Generics 3.0...

Adding support for generics is well underway but trying the GUI testing engine with WPF?

Help needs to be local, msdn needs to be installed...

Ohh well!

Autumn Nesting...

As my workload with Phurnace diminishes, DevRiot for .Net picks up.

Multi-dimensional array support is alive and well as the snapshot shows. Support for generics will take some time. The desktop and compact frameworks behave differently and the behavior of the engine needs to reflect this.

Well, the snapshot:

DynArray's P.S.

The one-click assert has been moved to a context menu where we will be able to provide a better way to handle assert conditions: greater than, etc, to return value, out parameters and post-test states...

DynArray...

The dynamic array, or data structures, logic is almost ready. We just need to add the dynamic shrinking to the nodes' context menu. Here we have a series of snapshots of how it's working:

1) Double-click the node to set or change the array length.



2) Type in the new desired length.



3) The tree readjusts itself.

One-click assert!

This is another of the progress snapshots: one click assert.

This feature allows the user to easily set the expected value, or range of values that an object should have. In this context a null or not null return value.

It does not matter if the object is private to a private field: just click away and forget about typing Asserts, PrivateObjects, or any of those rudimentary approaches!

Hit first, hit twice

Apparently USA's congress has changed the patent rules for a "first to the clerk" type of deal. Not good or bad, just a change in the playground.

DevRiot for .Net is coming along well, variable number of parameters and arrays are cleanly and dynamically handled.

Comparing usability with competitors...

Still doing interesting stuff with my buddies @ phurnace.

Prototipo; fundamentals, what fundamentals

The VS tool is coming along smoothly but a little bit slow. Phurnace's project has been quite interesting: started with a prototype with an rcp front-end and has turned into a WebSphere process server, web-services thing.

I have to admit that is highly interesting.

In this astonishing summer of news, there was this particular one about onshoring on cnn: an indian company was offshoring to Ohio some call center operations because the lower wages were not enough.

If the process and where economic value is created are not understood, there is little chance to success by trying anything else...

DevRiot for .Net is moving:

Forget about PrivateObjects, TestTypes, or writing code to create tests. Here is a snapshot of DevRiot for .Net:

Copyright (c) 2003-2007, efeKctive, L.L.C.

50 to 80 Marketing

Well, between working on DevRiot for VS 2005 and my friends' RCP project, I am having time to compare the two most used IDEs in the market.

It amazes me how the new bells and whistles added over time to these IDEs address so little the costs that are crippling most software shops. Testing and debugging shared 50% of the costs of a software project back when the first edition of the MMM came out. Now the same pair share up to 80% of the costs of a software project (according to NIST figures)

It is nice to have code-completion to the max but how does that reduce that 80%?

It seems that the game is about who messes things up the least, instead of who improves things the most.

Hibernahhh...

Well, we are on our way to the airport. The "vacation" is over. For those with questions about De vRiot architecture:

It is totally homegrown. It was built to not depend on Xunit (as opposed to Agitar's) to gui testing, let alone hibernate.

Happy flights!!!

.Net Progress, back to Bay Area, and other great escapes chapter...

Well, this RCP work does take its time but it is fun and it helps us. I have started to get the new architecture on Visual Studio together. This a little snapshot of the toolbar. (Not particularly different from DevRiot for Eclipse. And that's is the idea: lowering the learning curves...)

I also have been in touch with my friend to put DevRiot through the grinder of DataMining development. Progress but it will take time to show.

On another front, I have been meeting with some researchers from Santiago to start looking at the "writing engine" (so users will do nothing but look at test results and develop)

Finally, after 18 months I will be back to the States. The rest of the crew has been back several times but not me.

We will be visiting San Carlos/Bay Area. A new nephew is on the way :-}

I will post some pictures of an early spring trip to Costa da Morte which was quite pleasant: great waves and great seafood :-}

600--, 100++, Thread me!

Well, close to 600 downloads of the white papers. In little over a year, it seems like a good word-of-mouth.

The beta downloads have passed the 100 mark. With little prodding too. The interesting thing is that some of the downloads of Mac and Linux versions are coming from the Microsoft world(?)

I have been working more on my friend's project lately since we also have to pay bills :-} and working on the .Net add-in.

On the tool itself, another friend of mine came asking for help. This developer, like many others, was facing the daunting task of having to develop their own code plus the unit tests for that code.

In this case, there was also a lot of java, parallelism, and heavy database access involved. No wonder :-} Regrettably, our load and stress logic is not ready.

Hopefully, she will forgive me...

Variable Load!

Interesting visitors to our blog lately. Some have registered in the beta program, some have not.

We are looking at ways to cleanly allow the user invoke methods with a variable number of parameters. So far we are leaning towards double-clicking the parameters tab to insert a new parameter state tab.

The design on Load & Stress is going too. Before we try to measure memory and all that, we should make sure the user agrees with the state the object is after the beating. It requires some thought.

Why all that bloating?

As I move along with the VS add-in of DevRiot, I started to look again at the built-in features of VS.

What a mess! To end up asking the user the same information that DevRiot directly asks, there is an endless sequence of menus, options!

Orcas is following the same path. Why does the user need to deal with code? Because it executes faster? Obviously not.

That automatic code generation just works with native types. After that is back to set/get methods to set objects ready to tests. Or play PrivateObject nesting game.

Does it provide GUI testing for PC or devices? Nope.

Does it analyze build trees or AST? Nope.

Again, it is a step forward but short. Otherwise people would not still be asking "why white-box testing is ignored"

Beta FAQ:

A few questions have come up:

Do you Support Swing?

Yes. Actually, we are far along in that regard. We just wanted to release something that worked in J2SE and J2ME uniformly.

Swing is not an official J2ME package so we decided to remove it from the release.

How does the Private members access work?

Think of it as Visual Studio's PrivateObject but on steriods. And for Eclipse, too.

It is always there working for the user. But the user does not know it. The feature is transparent and does not require coding. It is also immune to refactoring changes.

It also works for all the types involved in a test (gui or unit): parameters, fields.

It also works like a drill: the user can click into an object state as deep as needed.

Is it only the plug-in/add-in?

No. The plug-in/add-in has two things in it: the plug-in/add-in logic and the reduced version of the engine. The plan would be to provide an automation server where the output of the plug-ins/add-ins are consumed and value added stats are gathered.

This could be provided as a service or as an attachement to SCM.

Virtual Solution 2209

Well, the actual performance increase over Nunit is 2209 times. Our average cost per test is around 8 ticks, while for Nunit 2.4 is 1700+ ticks per test.

So, I decided to look at the Test tools offered by VS 2005. Although a step in the right direction, not even close to the streamlining that most software operations need.

It is still a solution based on writing code (as if figuring out how to make code fail does not take time), they have to learn a never-ending list of attributes.

No wonder, people google for "why+white-box+testing+is+ignored" :-}

It allows to access private members (fields and methods) but their approach seems a babushka doll. It works fine if those fields are native types.

But if those fields are something more complex? Can the users apply the PrivateObject trick to types not-under-test?

After all, the type-under-test methods are affected by the internal state of any of its internal state components. Ah, the babushka doll!

For load testing, Visual Studio does not "require" to write code. It just puts the all the tests the user already wrote in a bundle.

What about daisy-chaining tests from the data layer or business logic layer to the gui to verify behavior across the layers? Even some tools, like code coverage, are there with the wrong crowd.

Hey, I am just trying to differentiate our product! ;-}

600+ Faster

As we polish the new architecture in .Net, we decided to compare the execution speeds of Nunit 2.4 and DevRiot.

DevRiot is still cookin!! Just considering the overall times, not the average, DevRiot is in the order of 600+ times faster. Plus it is also a GUI testing engine that runs in Windows as well as PocketPC.

Why do we consider this important? Testing and quality represents a huge percentage, according to NIST it could reach 80%, of a given project costs. Vista is another example of this efficiency problem.

The startling thing is very few, if any, high-tech strategy courses or implementations really address this. So which kind of strategy ignores altogether 80% of the problem?

A former, I think, SAP CEO mentioned the software industry needs to copy the auto industry. McKinsey & Co has written articles about it too. Microsoft Research aims in that direction also. But the facts seem to say something else. Just a look at the different internet forums will confirm this.

So if we want to improve the situation we need to use the scarce human time in more efficient ways, and let the computers use their cycles in something useful.

Anyways enough ramblings, here is the snapshot of DevRiot .Net

Weird Downloads!

Well, After announcing the beta availability really low key, we have had a great download rate. Although some weird downloads:

Somebody using msn downloaded the Mac version of DevRiot for Eclipse and some wip snapshots.

Switching to Visual Studio after some months of serious Eclipse plug-in development is a true shift in the way of developing tools. Enjoyable but different :-}