Skip to Content

Changes for page Testing

Last modified by Pascal Robert on 2012/01/03 10:53
From version 30.1
edited by Pascal Robert
on 2010/09/19 10:26
Change comment: add link to new thrash testing page
To version 31.1
edited by Ray Kiddy
on 2009/07/29 15:59
Change comment: There is no comment for this version

Summary

Details

Page properties
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.probert
1 +XWiki.kiddyr
Content
... ... @@ -1,34 +1,29 @@
1 -* [[||anchor="Approaches to Testing"]]
2 -* [[||anchor="Tools"]]
3 -* [[||anchor="Document Review"]]
1 +I have checked in changes to the ant build files. The result of these is:
4 4  
5 -== Approaches to Testing ==
3 +1) If you do a build as you used to do a build, there should be no change.
6 6  
7 -There are different kinds of tests and different approaches to testing. No one technology or approach will work for everyone. These are some of the relevant technologies and issues in testing WebObjects and WOnder applications and frameworks.
5 +2) There are two targets at the top-level:
8 8  
9 -"Framework testing" is testing that is oriented to testing the WebObjects frameworks or the WOnder frameworks themselves. "Application testing" is testing of an application or applications that are built using WebObjects or WOnder frameworks. There is obviously some overlap here. If one has an application, but with Wonder, one is obviously using and therefore implicitly testing both the WebObjects and WOnder frameworks. "Framework testing" is explicitly testing just the framework functionality in as general a way as possible. There are tests which seem to straddle these two. But one can look at the intent. For example, two of the applications in Project WOnder are the "AjaxExample" and "BugTracker." The AjaxExample application is just a list of pages showing things that can be done. Nobody would construct an app like this for real work. On the other hand, the BugTracker app was created to be used by real people for tracking real bugs. It also demonstrates and provides a test for advanced features in WebObjects and WOnder. An application like AjaxExample can be easily changed so that it is easy to test. BugTracker cannot be so easily changed. On the other hand, BugTracker is more like a real-world application and so we care about it a bit more than a demonstration project. It may end up being less convenient to test BugTracker, but it may be more important to test it.
7 +    test-all - does a clean and then build of frameworks,applications, and examples with Dinclude.tests=true.
10 10  
11 -There may also be a distinction between API tests, functional tests and perforance tests. In functional testing, one looks at some interface to an application and tests it to see if it does what it does. For example, if one launches the BugTracker app and clicks things and checks what they do, that is functional testing. If one looks at the API of a class, such as the er.extensions.foundation.ERXThreadStorage class, and determines what methods can be called on it and calls them, that is API testing. One can usually do API testing from a command-line interface and junit is probably the tool of choice for this. Functional testing is not so simple. One can manually exercise an app, which may be called the "clicks and eyeballs" approach. This works well, but does not scale. It becomes dull, people miss things, and we do not have robots to do it for us. One can use a test runner to interact with a running WebObjects/WOnder application. Performance testing often looks like functional testing, but the focus is different. It is not on seeing if things work, but how fast they work. In performance testing, one may have to use measurement tools which are not resistant to errors. In other words, performance testing may only work when everything else has been tested. One can do performance and functional testing at the same time, but perhaps one should not.
9 +    test-run - calls a junit test on selected projects
12 12  
13 -== Tools ==
11 +3) If the "test-all" target is invoked, then, in addition to any test sources being built in the other projects, the Wonder/Tests/ERXTest project is built. Is anyone involved in that project? If not, no harm, no foul.
14 14  
15 -Here are some relevant tools. It may be useful to search for their names in this wiki.
13 +4) I added a little stub of a test to ERExtensions. It does nothing right now.
16 16  
17 -* Junit and TestNG - for testing of [[user applications>>WO:Testing-JUnit and TestNG]] and for [[WOnder framework testing>>Project WOnder Frameworks JUnit Testing]]
18 -* [[Selenium]] - for both user and WOnder framework testing
19 -* [[WOUnitTest]] - for functional testing (Is WOUnitTest current and being maintained? rrk)
20 -* [[JMeter]] - for performance testing
21 -* [[Thrash Testing]] - for testing threaded operations in EOF
15 +5) I added a top-level target for "build" in Wonder/build.xml, just because it should be there.
22 22  
23 -Questions still to be answered include the different approaches one must take to different kinds of applications. For example, testing a "regular" WOnder app may be different than testing a "DirectToWeb" app, which is also different than testing a Java Client or a "Web Services" application. Different application types make some things easier and some things harder. One may need different approaches or different tools. Also, one may be deploying an app as a regular java application, or as a servlet in a J2EE container (e.g. Tomcat) or the application may be managed in some other way. How an application is deployed may change how it needs to be tested.
17 +Various things are needed to enable testing in a project:
24 24  
25 -== Document Review ==
19 +1) There must be a "Tests" directory in the top level of the project. So chill has spoken and thus it shall be done. Put junit test java sources under that.
26 26  
27 -There are many documents relevant to testing that should be evaluated for veracity, usefulness and relevance:
21 +2) There must be a parameter which defines the main test class. This could be a TestSuite, which would then invoke all the tests in the project. For example, the "ERChronic.all" target in the Build/build/build.xml file now includes the line:
28 28  
29 -* [[Testing-JUnit and TestNG>>WO:Testing-JUnit and TestNG]]
30 -* [[Web Services-Testing Services with Terminal>>WO:Web Services-Testing Services with Terminal]]
31 -* [[Web Applications-Development-Testing and JUnit>>WO:Development-Testing and JUnit]]
32 -* [[Testing-Load Testing WO Apps with JMeter>>WO:Testing-Load Testing WO Apps with JMeter]]
33 -* [[Testing-WOUnitTest>>WO:Testing-WOUnitTest]]
34 -* [[Web Applications-Development-Testing and JUnit>>WO:Development-Testing and JUnit]]
23 +&nbsp;&nbsp; &nbsp;<param name="test.className" value="er.chronic.ChronicTestSuite" />
24 +
25 +If there is no Tests directory in a project or if there are no sources in the Tests directory, then a build for testing does nothing more than a normal build.
26 +
27 +If there is no test.className property set in a project's target, then a build for testing does nothing more than a normal build.
28 +
29 +If there is no test.className property or there are no test classes in the jar files in the build root, then no tests from that project will be run. An example of a "test-run" appears below.