Version update – Alpha 4

It been some time since the last update but we have been busy lately trying to incorporate all the feedback we got into this version update.

so here’s a list of the things we managed to complete:

MSTest support

I’m happy to say that we added support for another popular testing framework.This will allow us to gather even more feedback and speed up the development of the product. At this stage only 2010 version is supported and only a single framework can be used in any single solution (i.e. trying to mix NUnit and MStest in the same solution will not be handled by Rapid-Dev correctly)

Improved Change Tracking

Tracking the changes that the developer makes on the source code is a fundamental ability that Rapid-Dev requires in order to produce correct results. As the version progress we add more and more scenarios and improve tracking of the developer operations. In this version we have added the ability to recognize and deal with adding of a new file into a project (either a test or a regular code file), and the handling of adding a completely new project which already contains code.

Support of Multiple IDE’s

We also dealt with the limitation of only working with one IDE at a given time and now the add-in can work with multiple IDE’s simultaneously. (as long as they are not working on the same solution)

Bug Fixes

several bug fixes were included in this release (exact details can be found in the release notes), hopefully making Rapid-Dev much more stable and robust. A specific annoying bug causing crashes during test execution was found and fixed inside the profiler.

We hope you will find this version much better and like always we apprciate and feedback you can give us regarding the product, if id made your life as a developer better , how do you think it can be improved and things that are not working properly. feedback can be left as comment here or send directly to the info mailbox.

Self Correcting Systems

One of the strategies I’ve learnt over the years is to prefer self correcting approaches over approaches that focus on always being correct and therefore lack in error handling.

The first time I’ve bluntly encountered the real difference between the two, was when I was worked on MMO game several years ago. That system was based upon keeping a vast amount of clients synchronized with a main server, so when we started we thought to always make sure that clients are in synch with the server. As the project progressed and become more and more complex, no matter how hard we tried there were always some other factor that at the end caused our clients to lose synch. Sometimes it were defects, sometimes network errors, and sometimes it just happened and we didn’t find out why. At the end we understood that our basic approach is wrong and started to think (and code) how to make our system cope with these cases and auto correct itself when possible.

Story of a Feature

When starting out to develop Rapid-Test, I knew that one of the main issues with the tool will be cases that it will not detect correctly the exact changes that the user will make to the system. Some of these changes will actually be made outside the IDE and since I didn't want to write a code analysis tool i needed some way to handle that.

That’s not to say that we will try to catch all those cases, but since I’ve learnt my lesson abut trying to stay 100% correct all the time. i knew i needed some mechanism early on that will enable he user to decide that something went wrong and to reset the add-in.

And that’s why we added the ”Tracking Reset” to the latest alpha version

Version Update - Alpha 3

Apparently there were some severe issues with the previous uploaded version which probably prevented the Add-In from working. We apologize for the this and hope that you would still give a chance to trying out the product.

Today we have uploaded a new version that fixed those issues along with two new capabilities:

Tracking Reset

At the end there are times in which Rapid-Dev might lose track of the actual status of the changes done to the code and might not 100% accurately select the correct tests to run. While this may be caused by internal defects, it can also result from changes to the code that takes place outside the scope of the IDE. A typical example would be bringing an updated snapshot from the SCM. The "Reset" ability allows the user to instruct Rapid-Dev to clean up its own internal structures, resulting on a full execution of all tests on the next build. This will cause Rapid-Dev to synchronize itself again with the correct code state.

The reset button is placed under the test menu bar:

for example when you bring a new update from the source control

VS 2010 Support

Rapid-Dev will now work inside visual studio 2010. nothing much to say about this.

(In order to check that the add-in is installed inside the 2010 just see if the Reset button appears in its right place)

Other Significant fixes

1. When dealing with large projects (containing many test cases) the Add-In would appear to hang during the initial execution. In te output window it will write that the tests are executing however it will not show any result for the execution. This was caused by limit in the message size between the Add-In and the test runner.

2. Fixed error in code change tracking - In some cases the tracking of what code was changed was getting confused due to assigning the changed code to the wrong project/dll. this resulted in the test selection to be wrong.

3. Fixed wrong handling of Test cases marked with [Ignore].

Known Limitations

There are a couple of limitation that users should be aware of and we are working on resolving:

1) the add-in does not support opening of two (or more) IDE's at the same time - this will cause the additional IDE to hang during start up. To avoid this just disable the Add-In before opening of the second IDE (using Tools->Add-In Manager)

2) Test execution is currently done synchronously. That is the Add-In wait until he gets the results and in the meantime the IDE is locked. in most cases this is not a big issue since the amount of tests executed causes a second or two delay. however initially when executing all the tests (or after a reset) this may take longer.

State of the Alpha Version

If you have downloaded the Rapid-Dev installer, you probably noticed that it is termed as an Alpha.

So what exactly that's mean?

Things That Rapid-Dev will do

The basic thing that rapid test does is track your code changes, analyze from them what are the minimal subset of unit tests need to be run, and executes them when you hit the build operation.

It's also reports the result of the execution back into the IDE letting the developer be aware of the actual state in which the unit tests are.

Rapid-dev also persists some of the data to the disk to allow closing and opening of the IDE/solutions and will also support working with various solutions.

All and all Rapid-dev works quite fast for small-medium solutions. other than the initial run (in which all tests are executed) on a typical build operation it takes only a few extra second to get the results.

Things that Rapid-Dev does not do. (i.e. Known Limitation

Rapid-dev only supports NUnit at this stage, it will not work with any other testing framework (MSTest, MBUnit, XUnit,...)

It only supports 2008, and does not work inside 2010 at this stage.

It is not as fast as it should and can be - the whole point of rapid-test is to supply fast feedback in a seamless way.

It is not 100% stable - we are still experiencing some annoying crashes from time to time and we are working on locating those annoying bugs.

It might lose track occasionally - There are some scenarios which we are aware of, in which the code change is not translated properly resulting in not enough/too much tests being executed.

And that's the thing we know about, we quite sure that they are a few more that we have not thought about. And that's why we still wanted it out there.

The alpha version is a way for us to gather feedback and to allow potential users to get involved in the shaping and creation of the product. So if you feel you will find such a product you can now try it out and let us know where and what to focus upon.

The Birth of a product

I started working on Rapid-Dev more than a year ago, at the time I had some extra time and i was looking how to use it to do something i really needed. looking back and trying to see what made me actually start that is quite interesting.

So what has led to the development of Rapid Dev?

Feel the need

the first thing that actually pushed me into this project, is a need I felt. It can be summarized very simply. If my IDE is smart enough to do a background compilation, why do I need to tell it to execute my tests every time? and than wait for the results? It should be smart enough to do that while im working and have the results ready for me when I need them.

I also remember that I looked at my development environment and found all sorts of tools/tweaks that were suppose to solve this. However all of them just came close, but none gave a full solution to the problem. I had TestDriven.NET installed which allowed me to execute the test from inside the IDE. I had my projects kick off an NUnit GUI when I pushed the debug button, and I had machine (CI server) that kicked in tests on every commit. All of these were good but again none answered my basic need:

I NEED to get a faster feedback from my unit tests.

Investigate the Market

Actually that's probably not a good description of what happened. I didn't went into a full investigation mode. I did felt a need, and at that time I heard about JUnitMax so I was quite sure that like most things, someone already solved this specific issue. It actually took me quite a while to really grasp that there was no such tool in the .NET world. so if I want one, I'll need to create one on my own.

During this search I also encountered a second Java tool - InfiniTest, which just made annoyed me. Those java guys have TWO solutions and the .NET has none!

On the up side, this made me confident that the need is legitimate and not pure personal, i.e. there is a market for this. Which really encouraged me to actually start working on it

And last, looking at JUnitMax and InfiniTest made me realize that they solved the problem in ways I not only i can repeat in .NET, but given my current background knowledge, I really can solve it technically wise.

Find the Courage

Having the courage to actually start was really the hard part. developing Rapid-Dev was not the first idea i had, and I've seen other had many good ideas as well. However there's a long distance from a raw idea to a full product. A good idea is just a starting point and the road from an idea into a full product is hard.

My initial doubts were like everything else technical. while I did know what exactly I needed to do, at first I thought to use the same approach we used at Typemock Isolator development. The problem was that duplicating that would be a significant effort, an effort I didn't want to invest. It took some digging and researching to understand that to solve my actual needs here, I just needed a subset of thee abilities, a subset which required much less effort to develop.

Next, I was really scared from the possible competition, during that time I heard rumors about VS2010 Testing Impact. At that time that looked too close to what I was about to do. And while I suspected that like always MS will only support her MSTest framework (and not NUnit), it was a risk I had to take. (and the thought of taking MS as a possible competition, even today is not a happy thought)

And if that was not enough, I don't recall the exact timing, but soon after I started I saw that Kent Beck has halted his JUnitMax development:

Putting Max on the Back Burner

that really made me think twice about continuing.

That's all that had to make me start, the combination of a really viable need, along with the technical ability to solve the issue combined with a strong inkling to disregard everything as a minor obstacle. I don't know if the decision was right or wrong, the road is still long. However, I am having fun along the way and I feel thats the important thing.

Rapid-Dev alpha released – Hello World!

I’m happy to announce that a new tool for developers has just been released.

Rapid test is a Visual Studio Add in that helps the developer be more productive and focused on coding. Whenever you build your code, Rapid-Test runs your tests as a part of the build cycle, reporting test failures as any other compilation error.

Rapid-Test uses test selection, in order to execute only tests which are affected by your last code changes, resulting in very fast feedback loop.

This is our Alpha release which means that we still have a few issues to fix but we wanted to release Rapid-Dev in this stage so that you – our user can try it out.

Currently we support NUnit tests and Visual Studio 2008 but we plan on adding support to other unit testing frameworks as well as Visual Studio 2010.

So what are you waiting for download Rapid-Dev from our site – and tell us what you think about it…