Categories Test Automation, General. You have to be logged in to execute this action. Manufacturer Open Source. Criteria: General. Test Automation. GUI element administration global repositories local repositories test object administration others:. GUI element identification attribut-related position-related virtual Id others:. Comments To write a comment, you need to be logged in.
There are no comments. Current one is 3. Add the bin and the lib folders to the path. Now open the console window, go to the Webtest folder and type the following command to create a new project with some examples ready to run.
You will be asked for the name of the new project to create. If you just hit [enter] the default name myWebTestProject will be used. Your newly created project contains some web tests ready to run, so that you can use them as templates.
You should see some activity in the console window after a few seconds and a html report file should be displayed in your favorite browser. In our project folder open the tests folder. There are a couple of auto generated xml and groovy tests. The important file is the allTests. Now imagine a manual tester checking all this.
Very soon he will get bored and unobservant, not to mention that resetting his session for every single test requires a lot of work. Is he really checking again all the possible variations at every full test? Test automation is key to better quality. Manual checks are more flexible and less expensive to do one time. They are more expensive and less reliable when tests need to be done over and over again.
We advise to do manual checks for everything that cannot break after it worked once. Everything else should be automated if the automation can be done without excessive costs. We want to use what we already know. We don't want to learn a new language for the test automation.
We want to rely on standard formats. Canoo WebTest follows the data driven approach. A proxy logs what pages you request and stores the results. It can then replay the requests and compare the results against the stored ones. You typically have to tweak this procedure to tell the program what parts of the page are expected to change.
The actual date and time are the most obvious examples. Every small change to your webapp causes a lot of these tests to fail. These failures must be manually processed to separate the "real" failures from the "false negatives".
Doing this is almost as tedious and error prone as the manual testing and is therefore discouraged testing professionals. Any automated test should fit snugly into your build process. An Example of this is Canoo WebTest itself. It contains a selftest that is written with Canoo WebTest. Every new build of Canoo WebTest triggers that selftest. You can explore this behavior online, starting at the Build Info link of the Canoo WebTest distribution page.
Note that this is very convenient for nightly builds and even for use with a continuous integration platform like cruisecontrol or travis-ci. It means starting a Java Application. This can easily be done with every build script language that we know.
To achieve this, our tests must not be dependent on random data. Also, the expected result must be clear in advance as opposed to the "guru checks output" approach, where a specialist validates changing results.
Tests must give a thumps up indication when successful and a detailed error indication otherwise. Well, this is pretty much like compiler messages. Functional tests do not replace unit tests. They work together hand-in-hand. Consider the following example: Your Webapp displays an html table that is filled with data from the database. The maximum number of rows should be 20 and if there is more data available, a link should be shown that points to the page that contains the next 20 entries.
If there is no data, no table should be shown, but the message "sorry, no data". We would test this with a no data b one row c 5 rows d exactly 20 rows e 21 rows f 40 rows g 41 rows. A naive way of testing this would be to manipulate the database maybe by using an administration servlet that we can call via "invoke" prior to calling the page. But this is not only very slow but also a little dangerous. What if two tests run concurrently against the same test database?
They will mutually destroy their test setup. What if the test run breaks? Is the state of the test database rolled back? The whole job is difficult to do for a functional test, but easy and quick for a unit test. A unit test can easily call the table rendering and assert the proper "paging" without even having a database!
What is left for the functional test is to assert that the table rendering logic was called at all. There is a lot more to say about unit testing. Refer to JUnit and the annotated references for further information. If you are not satisfied with any of the functionality, you can adapt it to your requirements. Having the sources, you even gain the ability to start the test in the debugger, revealing everything that goes on.
Canoo WebTest is free of charge. The downside is, that there is no guaranteed support. However, you can ask Canoo for special support incidents, a support contract and on-site help for introducing automated testing in your project.
Canoo WebTest is not restricted to any special technology on the server side. Canoo WebTest executes client side JavaScript just like your browser does. In fact, it uses HtmlUnit for this purpose, which can be seen as a faceless browser that is able to mimic the behaviour of e.
0コメント