Unit Test Utility - Test Driven Development as we move closer to PaaS

[Christopher_Mal]

I have to apologize for my silence on this blog. As always for us at Service Now there is never downtime or a dull moment.

Recently I spoke at an internal Service Now Sales meeting where, I and the other members of my team on Expert Services, we picked up the challenge Dale Brown (from our Global Program Office) made to make our new StartNow (Agile approach) to product development better. This is our first attempt at that, by incorporating a Test Driven Development (TDD) mindset to our Agile methodology.

Attached is an update set that can and should be applied to at least the development instances you are writing code in. The update set is supposed to provide an easy way to write and keep track of unit test. I wish I could take credit for the code that comes with this update set, but there were others in development that had a similar idea. I have to give thanks to Scott Marshall as he already had a great framework to build from (and instead of rewriting the world, I took his code and added a few minor things). I keep telling him and myself that great minds think alike and what he did is what I had in mind as well. To be honest I just tell myself things like that to associate with great minds and make myself feel good. 🙂 Yay! I'm smart! OK, to the point.

The fine print - this code has not been piloted yet by others in Professional Service, but I am hoping it will be soon. It is stable, but it is not feature rich. Currently it supports writing unit test for business rules and script includes. I am hoping through feedback in our organization and the community we can drive more requirements and features. This is a server side tool. There are so many great products for unit testing browser code that we left client test off this round.

If you choose to try this out - when you apply this update set you will see the creation of a new application called "Unit Testing". There will be several modules underneath. The definitions section is where you will create your test suites, test cases, and test definitions.

Normally, what I like to do is write the unit tests at the same time I am writing the functionality in my libraries or business rule.

The concept of a test suite will allow you to do regression test as you change and add more and more to your codebase.

I like to have a test suite per integration.

Test suites are made up of many test cases and I follow a specific naming convention when creating my test cases. Usually I like to have a test case per function definition in my script include.

Test cases have a setup and teardown section to prepare and cleanup, for test definitions to run and finish. Normally I have at least, but not limited to, two test definitions for each test case (sunny day and rainy day).

The flow of a test case is as follows:
1.Setup test
2.Iterate and run through test definitions
3.Assert on test results for each definition
4.Teardown

I will have some screen shots and examples on how this all works in my second blog post to this. Please stay tuned and as always, any feedback is appreciated. Cheers.

Unit Testing Utility v1.3.xml_.zip

Unit Testing Utility v1.4c.xml_.zip