Friday, June 16, 2006
sipxunit?
As the web layer and library layer gets more mature, we need to unit test more complex situations. For example, here is a test that I recently wanted to write: page X should be accessable to supervisor, supervisor is defined by having one or more users they supervise.
Right now, we seed our data for unit test by using webunit to drive web pages. This is very cumbersome because it can take a lot of time to write, prone to breaking (although also prone to inadvertant testing which is good), and against proper test driven principles using a layer to test the layer itself.
In addition, there's some data that simply cannot be seeded, for example results from other servers.
We knew about this limitation from the day we started, but it's unclear how to address this.
My latest thought:
I think we need to come up w/our own unit test language, library. For example I want to write this
new:user(mary) { set supervisors = new group(accounting) }
new:user(john) { groups = accounting }
system:statsServer { parameter:mockStatsServer }
By definition, this language is customized to sipxconfig, but maybe the syntax and constructs do not have to be.
Maybe spring w/it's near unlimited extensibility, and sophisticated AOP (support especically spring 2.0) will help here. Challenge with this approach is "resetting" the environment between each test. Spring has application-like events, maybe that's an approach. It's a language and constructs we already know.
- posted by Unknown @ 9:54 AM
| permalink
Comments:
<< Home
Another option for your test framework would be Ruby, since you are already using it. Ruby easily parses itself as a minilanguage, which means any fancy stuff or extension within a specific test definition can just use Ruby.
On a recent project, we automated white box tests for a B2B payment gateway via Ruby, and it worked very well, in terms of being easy to incorporate into the developer cycle. Most tests were defined in very simple scripts using "primitives" prepared by the framework, but for certain complex tests it was great to have full-on ruby iteration etc. available.
For the data loading we used a mixture of DB-specific loader tools (scripted w/ Ruby). For assertions about DB contents we used ActiveRecord, which you could also easily use for data loading.
A variant to my suggestion, which would allow you to write some framework stuff in Java/Spring, is to use Spring 2.0's simplifying support for JRuby. I.e. you could have a framework in Java, but it could load up test defs written in Ruby for instance. I haven't used this yet, but will be trying it out soon as it could fill a niche on my current project.
Post a Comment
On a recent project, we automated white box tests for a B2B payment gateway via Ruby, and it worked very well, in terms of being easy to incorporate into the developer cycle. Most tests were defined in very simple scripts using "primitives" prepared by the framework, but for certain complex tests it was great to have full-on ruby iteration etc. available.
For the data loading we used a mixture of DB-specific loader tools (scripted w/ Ruby). For assertions about DB contents we used ActiveRecord, which you could also easily use for data loading.
A variant to my suggestion, which would allow you to write some framework stuff in Java/Spring, is to use Spring 2.0's simplifying support for JRuby. I.e. you could have a framework in Java, but it could load up test defs written in Ruby for instance. I haven't used this yet, but will be trying it out soon as it could fill a niche on my current project.
<< Home
