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....

Moving!!

We will move the twitterfeed account from my personal twitter account to http://twitter.com/efeKctive in the next couple of days. Thanks!

Almost there...

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

Advice

We are evaluating .Net Obfuscation products. Any input is welcome here or @: beta At efeKctive dot com.

Thanks a lot in advance!

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...

Deployment is steady...

Well deployment of the engine is steady, as well as registering and unregistering. A few runs of these three together and some poking around the engine to make sure one last time and it should be ready to be downloaded! Happy new year!!

Registration is there...

The first part of deployment is ready, or almost ready. Tomorrow we will start on deployment of the engine itself. Happy Holidays!

Shallow waters

Finally we packaged a shallow/dummy version of DevRiot for .Net. The goal is to make sure the installers work correctly and package the resources needed by the tool to work. No functionality yet.

We are working on the full deployment logic.

They can be found here

Feel free to try it and let us know what you think at beta [at] efeKctive dot com

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...

Random thoughts

The GUI acts now as it should be (more stable). Just a couple of scenarios/bugs in the GG engine and the deployment phase should start in earnest.

The federal catch 22: labour market is in the doldrums. Stimulus vs. outsourcing? Spend more tax payer money that could be sent overseas in 2/3 years? Black Friday purchases shrunk almost 10% in compared to 2008. Not a seat for the faint of heart.

FormMinder!

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

Generics Generator getting a life...

We have hit a can of worms, actually a couple of weeks back, that made the automatic recompilation of tests algorithm working for generic types only or non-generic types only. Obviously this was not acceptable.

This algorithm was rewritten and it looks cleaner and working...

Crawling back to deployment

The recompilation process has hit a couple of obstacles while dealing with generic methods but we are working on them. But we have found a clean, simple way of deployment that is worthwhile trying...

Glad to be back!

After a short trip where I broke the only surfboard I had on the first session and was chased out of the line-up by a shark on the third day finding the last changes made to the engine were less than ideal is a piece of cake.

The trouble is already spotted, thoroughly examined, and almost fixed. The deployment logic will have to wait a tiny bit.

It is nice to see how big companies, and big research institutions continue using "Quality Advantage" on a regular basis.

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.

Nested Generics...

We are experiencing a little bit of trouble with the way nested generic types are being stored. In the meantime a couple of buttons/shortcuts were added so the engine can be disengaged when a series of builds trigger continuously DevRiot's automatic build.

Next week will be a simple install and finish the engine deployment method. Beta is just a short steps away...

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.

Pit Stop!!

From time to time things deadlock, etc. Well, for those occasions DevRiot lets you deal with them seamlessly...

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.

Progress one thread at a time...

Arrays and Dynamic fixtures seem to be stable. A couple of bugs that we'll need to get back to but nothing to keep us from moving on to threading/Load & Stress...

Objects

This is an snapshot of DevRiot latest build. It shows a run with a large amount of dynamic fixtures. Mainly System.Object in various shapes and forms (arrays, block arrays, etc) Depsite the number of failures, the execution times still are minimal. Enjoy!

Short Flight update

The block arrays logic is smooth now. There is a little glitch when mixing and nesting different type of arrays like TypeA[,,][][,,][]. But we are working on it.

Short Stop.

Block arrays have become stable. Cut and Paste of tree nodes will wait.

Tweeterish update

Making great progress. Generics is stable. Block arrays (of the form [,,,]) not so much.

Generics core

The interesting thing about last post is that the cpu utilization averaged 50% during the entire rebuilding of the suite (3.4 million tests) If memory is managed with common sense the throughput of DevRiot in multi-core machines with several cpu would be hard to match (mine is a duo)

On the down side the internal compiler choked at complex generic types like:

"ns1.t2<ns1.t1<system.byte[][],system.byte>,System.Byte,System.Int32>[][][]"

Problem solved. Smooth..

3,400,003 and counting...

We spent the weekend fixing an old disconnection problem when running large amount of tests. We fixed it. It works like a champ, it executed some really ineffient code for 24 hours straight without a bleep.

We also managed to squeeze 3.4 million tests with some complexity: runtime generics, different levels of validation and the engine ran like a champ. The pudding:

 

DevRiot for .Net Beta Update...

Having a little bit of trouble with nested generic types and bulk creation (25,000 or more) but other than stable an smooth.

BTW properties will not be supported for this beta. 

On Mac, again!

A renewed interest on DevRiot for Eclipse (Mac) has appeared in the last couple of weeks which is great. 

The problem was that the demo link inside the whitepaper was broken. The link has been fixed now. I apologize for the incovenience. Enjoy!

White-paper

Demo

Another Short Update

DevRiot for .Net is coming along well. We have spent extra time ironing out the code that deals with System.Object, interfaces, and abstract types because it is adding more dynamic input to an already dynamic engine. 

Since the user never writes code, tests are generated/executed on the fly, the former types add more complexity to the logic so the ironing of bugs turns more complex too.

Hit a unexpected behavior between the recompiling process of DevRiot and VS debugger. Specially annoying when handling 10,000 tests or more.

Feature complete!!

Finally, the feature set that is to be included in DevRiot for .Net is complete and stable. Next in line comes the installer and the delivery logic.

We are considering delivering a double plug-in . The users will install a Visual Studio add-in that will download DevRiot's engine. This way fixes will delivered easily.

This beta will support only Desktop Framework and unit testing. GUI testing, since it depends more on the running device, will be delivered at a later time when support for Compact and Micro Frameworks is polished.

A demo video will follow soon.

Another glitchy update...

We have been dealing, for the last several days, with an annoying timing issue that messes up all the symbols  displayed in the UI.

Cause & Effect:

One would have to think there is a correlation: a tech giant profit falls, they download our whitepaper. 

It seems that our wp has a reputation.

The beta is coming along great. I have had to devote time to help family, but I fixed bugs and DevRiot, I hope, it is getting close to be as useful as the whitepaper.

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!

Great Progress!!

The last couple of weeks have seen a lot of bug fixing, a more transparent GAC manipulation. Th engine is a lot more stable. It needs to be because it will also handle the GUI tests. Back to work...

The octopuss

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

The Road to Badajoz...

This is going to be my last post from Galicia, hopefully not last ever. I will be in Denver by the end of the month. The rest of the family is already there.

Moving a household across the ocean is quite an undertaking, even with movers. I have worked on DevRiot some: fixed several bugs, on the .Net Compact side.

Sendoff surfing session with the crew tomorrow. Next posting will be from the Rockies.

Possibilities

In case any of you were wondering, DevRiot runs in Java and .Net but it is not limited to those runtimes. It could run on C or C++.

It is a matter of resources available:-}

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...

Patently mine...

The question about the IP, there is only one owner of this puppy: me.

I hope this helps to clarify doubts.

Total Quality Slow Down:

It is always comforting to see that pretty reputable companies of all sizes get to efeKctive via searches like: "total quality management in software industry".

It makes easier the solo/self-funding effort. The summer months will be slower than previous months. Too many hours sitting in front of the keyboard take a toll on anyone's back, wrists, etc.

Hopefully, my new surfboard will be here by our arrival.

So tomorrow, we are heading to Amsterdam to visit my sister. Pictures will be coming...

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...

Plugging the plug-in

We are paying the error of working while sick on a key piece of code regeneration. Bad code, or at least worse than usual, that needs rewriting.

But it also has given us the opportunity of thinking about deployment.

We are toying with the idea of adopting "perpetual delivery" mode. Since the engine is not larger than 150K, downloading it can part of the add-in setup.

Generating Generics...

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

Deploying the report,

Still making a lot of progress with suite recompilation and integrity.

Also some time has been spent on figuring out how to deploy the tool while minimizing the IP exposure.

There is VS Gallery and other channels. Obfuscation is a good deterrent but it needs help from other angles...

From the lonely tree to the red sound (Progress report)

The recompilation process is moving slowly but solidly. As anyone might have guessed bugs have been uncovered and are about to disappear...

Letter to My Sunday Readers:

I am still in the process of getting visual studio/sql server back in a workable condition. If I could find the misplaced XP cd I would rebuild the whole thing.

Watching a lot of movies though...

Chasing hotfixes!!

It is one of those days: VS does not want to continue working, not even with the hot fix. Reinstall time. It had been a long while since VS coughed up like this.

What else to do if not watching a movie on the mac while xp works?

The mac's codecs need updating.

Wonderful!!!

The S option seems to be a viable option!

Good ol' SQL improved the serialization of tests by leaps and bounds.

Now it takes less than minute and a half to create and store 5,000,000 tests. Before this much time was needed for 100,000.

The S Option

Given the enormous amount of tests can be generated with DevRiot, our old serialization architecture is proving not up-to-par.

SQL seems to be most logical way to handle this.

Well keep you posted. Sorry for the inconvenience!

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...

Beta Sign-up problems.

It has been brought to our attention that the beta registration page has been behaving erratically.

For those who have problems please send an email to the following address:

beta@efekctive.com

We apologize for any inconvenience.


This is an old post. Beta registration occurs at installation. Thanks!

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).

Almost Context Full...

The context manager is 60% done. 4 snapshots of the context manager at work: assertions, cleaning up, etc.

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:

Short...

Now the generics engine can handle pretty much everything it is thrown at it.

The first ever Visual Unit Testing tools is coming your way...

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...

Back on line!!

It arrived! After several weeks of waiting the snail mail to deliver the laptop converter. It arrived.

It was kind of an experience trying to order the spare part from here having bought the laptop in USA.

It would have been great if the surf had been less chaotic but winter storms can be messy around here.

Anyway, it is time to get back on track with the .Net beta :-}

Stop!!

This is a not so good progress report. The development laptop batteries are not charding and the converter is not working :-}

I guess Dell will get another support call from around here.

Other than that, adding support for collections and modifying generics compilation is coming along well.

Time to wait...

Tick, Tick, Tick, Tick, Tick II

Well, I just tried VS 2008 testing tools.

Ahh, what a way to get it wrong from marketing to development.

I will continue working on the GUI testing engine and device support for the Compact Framework. I will keep the performance figures for later...

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...

May I Compare...

It is funny but blog-post.html from 05/07 seems to be pretty popular around the globe these days. I wonder why it is so special...

And it is interesting how readers compare the execution speeds of DevRiot .Net with DevRiot Java, specially since the Java data comes from a 1,000 tests run on Mac PowerBook (PPC) .

I have to admit that I have been redoing some code that looked good few weeks ago and now not so much...

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.

Slow drip...

Sometimes things happen in a way that makes you wonder.

I have not worked on DevRiot's eclipse plug-in in ages. Obviously, I am concentrating on .Net since Visual Studio 2008 is going to be released soon.

But the funny thing is that the demo of DevRiot running the GUI testing engine on J2ME has become pretty popular this month.

How information flows in the business world is amazing!

Needless to say, it is going to be a lot easier to implement the GUI testing engine for .Net than for J2ME. Everyhting is already in the IDE (VS 200x) On the other hand getting the same device support on Eclipse/J2ME is like secretively impossible. Back to work...

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...

Sweet deal...

We just got a really good offer to participate in a major tech event next year. Obviously we were caught off guard (money and time wise) We will have to do some figuring out...

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.

Roasted Chestnuts...

Fall arrived! Harvest time! One of the advantages of living close to one's farming uncle is that you get the goodies. This year are outstanding tomatoes, last year to-die-for wild "setas" (shiitake mushrooms)

Last night, roasted chestnuts picked from trail. And some pictures to share:

The neighborhood:

A day trip to Praia das Catedrais:

P.S. Why the overreaction? Some research units get caught reading DevRiot's feature plan and then tell the whole company to stop visiting the site? It should have touched a weak spot :-}

Beta FAQ 2:

For those research units interested in what is coming down the pipe:

*) The .Net beta will include Gui-Off: that is the ability of running the gui execution engine off the screen to increase throughput.

*) The Test Writing Engine will not be included in yet. We need field-proven execution engines before design on the writing engine continues.

*) The eclipse/java version will be overhauled after the .Net beta is available: it will become an Eclipse feaure, etc.

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.

Protect thy brand

It should have hit a nerve or something but after I published the latest progress snapshot. One of the monitoring bots brought a botfriend that specializes in brand and IP protection (?)

Thanks for keeping our IP in good hands...

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!