Thinking of Testing… Enter EasyTest

Testing is a new buzzword in a modern software development world. And we all recognize the importance of it (I hope). However for some of us testing hasn’t found its way into our development process.

But why is that ? The usual answer is this: I do not have time to spend on that.

I believe that in most cases this answer comes from small companies or even one man shops. Do they even have alternatives?

1. Write bug free code. That can work when the project is small. Of course as the time passes any changes you make to the code may interfere with other parts of the project and produce unexpected bugs
2. Target projects that you are able to test manually. Those projects have to be relatively small and the developer on every release have to go through all the functionality and test it manually

A real use case of EasyTesting
I think most of you remember the changes that DX introduced in v10.1 regarding core functionality and application model. To refresh your memory I will point you to this Application Model Migration Guidelines article. When DX started to build core parts of XAF many years ago they chose the technology that had limitations (don’t we always do that?). Luckily for us DX is always prepared for such scenarios. From the very beginning the team, using the EasyTest framework, described all core functionality in a platform agnostic way. That move was a life saver! Developers could rewrite the core and be comfortable about the results, as long as they satisfy the existing EasyTests.

Easier said than done, some of you may say. Not quite true! Let me compare it with traditional testing.

Unit Testing: Mostly used for low level testing and does not ensure bug elimination. One reason is that when units collaborate in a higher level the behavior there is unpredictable. And unit tests do not operate at that level.
Functional Testing: In many cases it eliminates the need for unit testing. The reason is that you are testing how the system operates in a higher level and that of course includes the collaboration of your units. So when you do functional or behavior testing you describe your requirements in a very readable way to target the appropriate level. Using this kind of testing assures that your tests will be less fragile than unit tests. The problem here is that tests may require a very good knowledge of every part of potentially large system (XAF). Which means that it may take a considerable effort to set up full set of tests.

I believe EasyTest comes to the rescue here. XAF architecture defines the boundaries with the environment. The interaction with the user comes from the Actions. We mostly have to deal with business objects which that are bound to a UI in a transparent way. Using all that together we can build a domain specific language which is exactly what EasyTest is.

So If we try to write a test in pseudo code will look like this:

StartApp 
Login 
GoToView 
ExecuteThatAction 
CheckThisPersistentObjectData 

Which gives us the following:

1) It is non chatty
2) It is very readable
3) It tests our application data. Remember that XAF applications are data driven? Testing the database data makes our tests platform agnostic as well!
4) It did not take long time to write it. Just try to remember how many times you went to a view and hit an action to check a for a behavior.
5) It is already very close to EasyTest’s original language.

To learn the basics I highly recommend to start from here. To learn more than the basics, you can watch this great webinar from Gary Short Functional testing deep dive. And, of course, follow my next posts as I am going for a deep dive as well.

1. How to run EasyTest scripts from code
2. How to implement a custom EasyTest command
3. EasyTest and test data

Is there anything else that can raise the quality (and, perhaps, the price) of your products apart from an excellent testing framework? If yes, I’d like to hear about it and we can blog about it too

Happy EasyTesting!

Free DevExpress Products - Get Your Copy Today