Unit Testing Framework

Unit Testing Framework

  
http://thedevelopers.co.uk/page/Unit-Testing-with-the-OutSystems-Agile-Platform

I'm currently developing a framework to allow unit testing of Agile Platform eSpaces. I'm keeping a blog (see above) as I progress with development of the framework - if you're interested in this topic you might like to have a look. I'll be happy to release it as a download in the Forge when it's completed. In the meantime, if you've an opinion about this topic or features you'd like to see included in it, please feel free to leave me a comment.

The main difference between the framework I'm developing and the ones I've seen so far is that this one isn't based around UI-level testing (Selenium etc). Instead, this framework is designed for unit testing the publicly exposed actions and functions of Core Business Service producer eSpaces (consumed by applications). It's basic design was suggested to me by two of OutSystems own developers I met while on the Delivery Manager boot camp in Portugal recently, based on a tool used internally by OutSystems for unit testing parts of the Agile Platform itself.

As well as using the framework myself on my own projects, I'm hoping that the availability of such a tool could help anyone in the future who is looking to adopt Agile Platform but who runs into uncertainty from their company due to Unit Testing (in the normal sense) not being easily available with the platform.

Screenshot of Unit Testing Framework executing series of unit tests
Hello Andrews.

It looks very nice :)

Can you share your aproach on the subject? I'm guessing that when using the tests one has to indicate the inputs and expected outputs of each action, right?

Reading your blog, I've noticed that you plan to only have support to test public actions. Is there a motive for that. 

I think that it would be great to support tests of provate actions also.

By the way, it would be great to have such a tool in Forge. Maybe someone would join the team and help out with the development ;)

Cheers.
Pedro Cardoso wrote:
Hello Andrews.

Can you share your aproach on the subject? I'm guessing that when using the tests one has to indicate the inputs and expected outputs of each action, right?

Reading your blog, I've noticed that you plan to only have support to test public actions. Is there a motive for that. I think that it would be great to support tests of provate actions also. 

Hi Pedro,

Thanks for your feedback. Yes, for some actions it would be sufficient to pass in the input parameters then check the output was expected (for example, a function whose purpose is to do some string manipulation, perhaps). For more complex actions the test may require extra steps. For example, to test an action that makes changes to your data, the test may need to first arrange some data in the database, then call the action, then run a query to verify the data changed in the expected way.

The scenarios I'm thinking of for this kind of database-related testing would be where the core business service eSpace exposes entities as read-only, and provides public actions to perform any changes to those entities. For example, in the Home Accounts application, one of the core business actions is to change the amount of a previously entered transaction. If that transaction is actually part of a transfer between accounts, then actually two transactions should be updated, so the amount on each side still balances. That's something my unit test would verify happened.

Because the tests may be changing data in the database while they run, that's the reason for each test rolling back any changes it made at the end of the test - I don't want my tests to make any permanent changes to the data that's alrerady in my database. Not that I'd ever run the tests on live, they would only be run in the development and perhaps QA environment.

The reason for only allowing testing of publicly exposed actions (not private ones) is because the purpose of my unit testing is to verify that the Core Business Service eSpace has (and keeps) the behaviour I expect it to have from the consumer application's point of view. The consumer can only access the public actions of the produce eSpace, so that would be the limit of my test. Also, the eSpace containing the unit tests is itself a consumer of the Core Business Service provider eSpace, so the public actions are the only ones I can add a reference to and call.

Hope this makes sense!

Kind regards, Andrew.
Pedro Cardoso wrote
I think that it would be great to support tests of private actions also.

Pedro, I've just been thinking about this more, and I guess you could use the framework to unit test private actions if you're happy to define the unit tests for those actions within the same eSpace as the actions themselves. For safety, I'd maybe add an extra check at the start of each unit test to make sure it's not been run in the production environment. Cheers!
Heya,

screenshots look nice :)

really interested in this.
I have made something myself as well, but due to time constraints I stopped developing it.
Are you going to release it on the forge and/or need help?
Statler & Waldorf wrote:
really interested in this.
I have made something myself as well, but due to time constraints I stopped developing it.
Are you going to release it on the forge and/or need help?
 
Hi, thanks for your feedback. Yes, the plan is to release it on the forge when it's feature-rich enough. The area I'm working on most at the moment is around the construction of the unit tests themselves, and working out ways to make this as quick & simple as possible (so developing the tests for a project doesn't become harder than developing the project itself!) I'd really appreciate it if you could maybe review the framework after I've got a little more done on it, to see how it compares to what you developed and if you can see any areas for improvement. Before release to the forge too, I think it would be good for a few people to have a go with it, just to make sure it works in a variety of environments, and maybe help out with extra development on the library of "assert" actions. Also, at the moment there are a couple areas where I use a C# extension to do stuff like WSDL parsing and dynamic web service invocation. I did that for development speed, but someone with more expertise on doing that kind of thing within Agile Platform might be able to re-write those bits as proper actions, which would be better as it would make the framework run on Java as well as .NET.
Just contact me if you need my assistance :)