Once Ant is working, you'll need to obtain copies of both +
Once Ant is working, you'll need to obtain copies of both JUnit and HTTPUnit. JUnit is a framework to automate the running of unit tests, and HTTPUnit provides an abstraction layer for HTTP. These are both needed to @@ -36,50 +37,54 @@
The final step is to replace the server properties in the build.xml file so it will know how to talk to your server. You will need to give it a base URL, a username, and password for that user. -are the "JVMARG" lines in the "JUNIT" section. ). In the near -future, this will be moved out of the subdirectories and either -into the toplevel build.xml file or into a configuration file.
-You should now be ready to run the tests. Go to your server's
-"packages" directory and type source ./paths.sh to set
-up your classpath. Now type ant. Ant should find the
-toplevel build.xml file, check that it can see JUnit, compile your
-java files, and finally call Ant on each of the sub-directory
-build.xml files to run the tests. You should be shown a report of
-which tests failed and which succeeded.
You should now be ready to run the tests. Go to your
+server's "packages" directory and type source
+./paths.sh to set up your classpath. Now type
+ant. Ant should find the toplevel build.xml file,
+check that it can see JUnit, compile your java files, and finally
+call Ant on each of the sub-directory build.xml files to run the
+tests. You should be shown a report of which tests failed and which
+succeeded.
Within the function, a typical unit test involves requesting a page, saving the result, checking the HTTP return code, then parsing out various strings to check for page functionality. The -return code should be checked with "assertEquals", and any other -checks should be performed with "assert". Use of "assert", -"assertEquals", and exceptions allow JUnit to accurately report -where a test fails.
+return code should be checked with "assertEquals", and +any other checks should be performed with "assert". Use +of "assert", "assertEquals", and exceptions +allow JUnit to accurately report where a test fails.If you need to create a set of tests for a module, the first step is to create a directory tree beneath the module directory. The current convention is to put all .java files in a -"/java/src/com/arsdigita/acs/module name/test" directory. -The module name should be the ACS module name, but with all -dashes removed and with appropriate capitilization. All .java files -that you create that contain test cases must have the word Test in -the filename. All of the classes you create should be in the -com.arsdigita.acs.module name.test package, and should -import "com.dallaway.jsptest.*" and "junit.framework.*" (and -optionally, if needed, com.arsdigita.acs.acsKernel.ACSCommon). -Next, the public class needs to extend "TestCase", and provide new -method definitions for "suite()" and the constructor. Typically, in -the constructor, you should extract the system property -"system.url" to determine which server to test against.
+"/java/src/com/arsdigita/acs/module name/test" +directory. The module name should be the ACS module name, +but with all dashes removed and with appropriate capitilization. +All .java files that you create that contain test cases must have +the word Test in the filename. All of the classes you create should +be in the com.arsdigita.acs.module name.test package, and +should import "com.dallaway.jsptest.*" and +"junit.framework.*" (and optionally, if needed, +com.arsdigita.acs.acsKernel.ACSCommon). Next, the public class +needs to extend "TestCase", and provide new method +definitions for "suite()" and the constructor. Typically, +in the constructor, you should extract the system property +"system.url" to determine which server to test +against.