LOGIN | REGISTER NOW | SUBSCRIBE
 
print Printable version 
Most Read Latest News Blog Resources
Three non-programming books for your booklist
Aside from programming skills, developers should know how management works and how to oper...
A fast start for an open-source cloud
Three developers from the OpenStack project talk about its already-thriving community and ...
Integration Watch: The intractability of parallel programming
Not much progress has been made in the field of parallel programming. What can be done to ...
Windows & .NET Watch: LightSwitch turns up
Microsoft's newest development environment will need to go a long way to fulfill its poten...
Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter


            iphoneapp GET THE APP!

Integration Watch: Testing via models


By Andrew Binstock
April 15, 2010 —  (Page 1 of 3)
For the past several months, I’ve been discussing alternatives to unit tests for both designing and validating software. In a pair of columns in particular, I discussed using functional test tools for designing the code implementation.

One commenter on those columns inquired, “Why functional tests?” This is a valid question. Unit tests are simply too low-level. They test too little. And many small tests taken together tell you only that the individual grains of code work correctly. They say nothing about whether the functionality works in the large, nor whether it’s anything the customer asked for.

Functional tests should reflect a function specified in the requirements or in some kind of feature repository (these days, defect trackers fill this function all too often). Using functional tests correctly orients the design and code to the goal, namely delivering what the user wants.

Higher-level tests, such as user acceptance tests, are too coarse for my taste. One feature that a user might demand could have multiple parts consisting of dramatically different actions. For example, suppose a user acceptance test is at sub-second response time. This will surely require numerous optimizations. A single UAT of the response time will tell me whether I’ve succeeded overall, but is no use in designing and validating the individual changes I’ve made.

This view is not universally accepted. Ken Pugh, who gave one of the keynotes at the recent Enterprise Software Development Conference in California (produced by SD Times publisher BZ Media), told me in the after-party that when he sits down to write code, he always starts with a UAT as the defining goal for what he’ll work on. I trust Ken when he says this, but I don’t see how I could apply this. Much of my development work is simply not a broad-brush endeavor. It frequently includes small maintenance efforts, or optimization, and so on. These tasks rarely can be encapsulated in a UAT.

But the user orientation that Pugh finds in his approach, and that I echo in functional tests, is a key differentiator from the mainstream TDD orientation. There are approaches to testing that take the core concept of serving the user even further. Principal among these is model-based testing (MBT). I realize I tread dangerous ground here; the idea of using models is as appetizing to most readers as a tablespoon of brewer’s yeast or cod liver oil. And yet, there is much to recommend it.

 Related Search Term(s): testing

Pages 1 2 3 


Share this link: http://www.sdtimes.com/link/34264
 

Comments

04/16/2010 09:46:39 AM EST

Great article. Thanks for the information. Another tool that I've looked into is http://testoptimal.com/. An integrated approach to testing web applications using model based testing.

United StatesRob


04/19/2010 11:15:56 AM EST

As you suggest, we agree in principle, but probably not precisely in terminology. There are acceptance tests that are specified the user and there are acceptance tests specified by developers. For the response time example you mentioned, the acceptance test specified by the user might be the response time from a button press to a result display. The overall programmer designer could subdivide this test into developer acceptance tests for the network time and for the server time. As you suggest, the server time test helps validate whether the system is responding within the time, but the test does not help in figuring out how to make the server deliver quickly. The tests below this point are definitely functional tests. The gray area is whether the server time test should be called a functional test or an acceptance test.

United StatesKen Pugh


04/25/2010 09:58:27 PM EST

As Rob pointed out, another MBT tool is TestOptimal. It's a simple yet effective MBT tool for testing web applications. Check out this 4-part tutorial by Ray Vizzone of Recommended Testing Labs: "Model-Based Testing for Web Applications with TestOptimal", http://blog.testlabs.com/2009/10/model-based-testing-for-web.html.

United StatesYaxiong


Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading



 
 
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 9/1/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
VMworld hops to it
Data center operating systems play a big part at VMworld, but it's still too soon.
09/02/2010 01:42 PM EST

Certificate program for secure cloud computing
The Cloud Security Alliance introduces user certification.
09/01/2010 04:20 PM EST

What does the Army's Crusher tank and RIM's tablet computer have in common?
RIM plans to use Crusher tank technology on its yet-to-be-announced tablet.
08/25/2010 04:16 PM EST

 

Events calendar tab
Intel Developer Forum
9/13/2010 to 9/15/2010
San Francisco
Intel

JavaOne & Oracle Develop
9/19/2010 to 9/23/2010
San Francisco
Oracle

Oracle OpenWorld
9/19/2010 to 9/23/2010
San Francisco
Oracle

ESC Boston
9/20/2010 to 9/23/2010
Boston
TechInsights

High Performance Computing Financial Markets
9/20/2010
New York City
Flagg Management