Browse files

added coverage and usage sections to README

  • Loading branch information...
1 parent 7a41b5b commit d76b0a23c71baa5d9d4e14b1988f33190185652c Austin Montoya committed Dec 27, 2011
Showing with 45 additions and 0 deletions.
  1. +45 −0 jmeter_tests/README.markdown
@@ -9,6 +9,51 @@ Currently, tests for each service description are the only implemented functiona
however, a library of utility functions has been created to easily create other black-box
functional tests should they become useful and/or necessary.
+## Coverage
+The tests cover each of the individual service descriptions available on a running node.
+Each service description is extracted from the `/services` url, then compared against
+a javascript object containing the expected values. The expected values in these ojbects
+have been assigned according to each respective Network Node Service Description Data Model
+found in version 0.24 of the LR Technical Specification.
+When appropriate, hard-coded values
+are used as expected values and simple comparisons are made. For example, the `service_type`
+property is part of a fixed vocabulary ("publish", "access", etc.) and thus a static assertion is made.
+In cases where a value is required by the spec but can be dynamic (such as a timestamp), an
+appropriate function is applied to assert that the value is indeed in the range of valid inputs.
+Properties marked as optional in the specification are also accounted for, and are evaluated
+only when returned from the server.
+Optionally, an extra check can be made for extra keys not defined as part of the spec. This
+assertion will raise an error if a key-value pair is returned from the server but not found
+as part of the expected object. Since the Network Node Service Description Data Model is allowed
+to have additional custom fields, this check is currently OFF by default.
+The current commit also includes a separate test for the `/policy` data model that functions
+in a manner identical to the aforementioned service description tests while testing for
+the appropriate values for that service.
+## Usage
+The node to be targeted can be set using the LRNodeAddress and LRNodePort User-Defined Variables,
+which means that running the test is very flexible with regard to environment. Because of its independence
+from the actual source code, unlike the python nosetests,
+a user can decide whether to test a remote node or one found locally with minimal configuration changes.
+That being said, it is also to be noted that these tests are NOT designed to be a replacement for the
+nosetest unit tests, which provide a much more complete and robust way of testing an existing
+Learning Registry installation.
+This test was designed and developed using the GUI version of jmeter 2.6 on Windows. When finished,
+the configurable pathnames were changed to work with a headless version of jmeter running on
+Ubuntu Server 10.01. Each functioned identically; however with the headless version, an output file
+must be specified to view the passes/failures. The latter of the two configurations is what
+can be found in this repo.
+Please refer to the [jmeter project page]( for more information on how
+to properly install, configure, and run jmeter.
## Structure
### File Hierarchy

0 comments on commit d76b0a2

Please sign in to comment.