Three key parts of automated testing tools

Today, I saw bret pettichord's article:

Http://www.io.com /~ Wazmo/blog/archives/2009_04.html #000293

 

The meaning of the English word "harness" has been vague for a long time. It seems that this article has been quite clear.

Harness:

N.

(Full Set) harness, a rope tied to the body

Vt.

Horse tools are built on a pair of trees, which use (rivers, waterfalls, etc.) to generate power (especially electricity)

 

However, it terms seem a little difficult to translate.

 

 

A test harness is responsible for executing tests and collecting and reporting results.

The testing framework is responsible for executing tests and collecting and reporting results. (Here, harness translation should be appropriate for the framework !)

 

Let's get down to the truth and talk about this article. Here, Bret pettichord mainly wants to clarify three key components of automated testing tools: script language, driver, and framework.

 

For watir, watir itself is a driver (browser-driven), Ruby is a scripting language, and the framework can adopt the unit test framework test: Unit, rspec, cucumber, and so on, you can also develop it on your own.

 

Three key tools for automated testing: language, driver, harness

When I started working on watir, I was pushing a vision for automated testing. this vision still motivates my work with watir. A couple of years ago, Brian Marick told me open-source developers shoshould share their vision and let the community know why they built the tool. here's the vision.

There are three essential elements of an automatic testing system: language, driver and harness. your tests need to be written in a language and you need a language to extend your testing system. I 've long believed in scripting ages, such as Perl, Python and Ruby. I find that testers are more productive with them and find them easier to understand and use. I have reasons why I prefer Ruby, but there are other good automated testing systems written using other scripting ages. in fact over the years, I have built testing frameworks in Perl, Python and VB, usually building on versions ages that were already in use at the client. my emphasis on full-featured programming ages was a contrast to the proprietary ages that had been commonly used in your cial testing tool suites. I had no patience for them.

There are lots of different ages to choose from. finding a suitable driver, however, was often more difficult. A driver is what you need to drive your application. watir is an example of a browser driver, suitable for Web applications. often the driver determines the language you use. years ago, I used has CT as a driver for a command line application. please CT used TCl as its language, so the suite was written in TCl. I developed watir because I wanted a browser driver in ruby. watir was our solution for Web application testing in ruby.

The third thing you needed for a testing system was a harness. when we started, we all used test: Unit, a ruby test harness designed for unit testing. we found that it cocould be adapted for functional testing. more recently, watir users have been using rspec or cucumber as their test harness. A test harness is responsible for executing tests and collecting and reporting results. some people like to build their own test harnesses instead of using one of these.

I developed this vision while working with your cial testing tool suites like silktest and winrunner. these packages are often referred to as tools, but I found that they actually comprised a collection of integrated tools. they had predefined usage expectations that often didn't match actual tester needs. data-driven testing, for example, required us to break down the suite and then reassemble it in a more suitable configuration. I wanted testers to be able to identify the individual tools that made up a testing system.

Using new watir users have trouble identifying where watir (the driver) ends and Ruby (the language) begins. but learning this is key to becoming a proficient user. i'm told that some java teachers don't like their students to use an IDE (such as eclipse or netbeans ). instead they want their students to learn to use the required tools separately -- the editor, the compiler. this way they learn the function of each tool. in the same way, I 've also wanted testers to understand the functions of the different tools and components used in a testing system.

We often get questions from new watir users whose answers are obvious once you understand this. Can watir read CSV files? Can it do date math? Can it read from a database? The answer to all of these questions is that watir can't do it, but Ruby can. no browser driver cocould do these things (it wocould be like asking whether your compiler supports search and replace), but any full-featured programming language can. it's just a matter of finding the library to do it. these questions are raised in the first place because testers are used to using your cial tool suites that were closed systems. so you only got the ability to do these kinds of things if the vendor added it to the package. watir is part of an open system, so all the libraries are there already and more are being written all the time, often by people who are not part of the watir community, per se, but rather part of the larger Ruby community.