Author: fschumacher
Date: Fri Mar 6 21:07:14 2015
New Revision: 1664721
URL: http://svn.apache.org/r1664721
Log:
Small markup cleanup in docs.
Modified:
jmeter/trunk/xdocs/nightly.xml
jmeter/trunk/xdocs/usermanual/component_reference.xml
Modified: jmeter/trunk/xdocs/nightly.xml
URL:
http://svn.apache.org/viewvc/jmeter/trunk/xdocs/nightly.xml?rev=1664721&r1=1664720&r2=1664721&view=diff
==============================================================================
--- jmeter/trunk/xdocs/nightly.xml (original)
+++ jmeter/trunk/xdocs/nightly.xml Fri Mar 6 21:07:14 2015
@@ -32,9 +32,7 @@
<br/>
They are intended for use by developers and others wishing to help with
resolving JMeter bugs.
</p>
- <p>
- <span style="font-size : x-large"><b>These builds should not be used in
production.</b></span>
- </p>
+ <note><b>These builds should not be used in production.</b></note>
<h2>Where are the nightly builds?</h2>
<p>JMeter CI builds are currently run by Jenkins and Buildbot</p>
<p>These are located at:
@@ -70,11 +68,11 @@ Unpack all the archives into the <b>same
</p>
<h2>Warning - please note!</h2>
-<p>
+<note>
<span style="font-size : large">
<b>The nightly builds may or may not work properly - or at all.</b>
</span>
-</p>
+</note>
<p>
If there is a problem with a particular version,
it may be worth reporting this on the JMeter-dev mailing list and/or
trying again in a day or two.
Modified: jmeter/trunk/xdocs/usermanual/component_reference.xml
URL:
http://svn.apache.org/viewvc/jmeter/trunk/xdocs/usermanual/component_reference.xml?rev=1664721&r1=1664720&r2=1664721&view=diff
==============================================================================
--- jmeter/trunk/xdocs/usermanual/component_reference.xml (original)
+++ jmeter/trunk/xdocs/usermanual/component_reference.xml Fri Mar 6 21:07:14
2015
@@ -1021,17 +1021,15 @@ are two interfaces you have to implement
HTTPSampler. The servername, port and get images are set by AccessLogSampler.
Next,
the parser is called with integer 1, telling it to parse one entry. After that,
HTTPSampler.sample() is called to make the request.
-<code>
-<pre>
- samp = (HTTPSampler) GENERATOR.generateRequest();
- samp.setDomain(this.getDomain());
- samp.setPort(this.getPort());
- samp.setImageParser(this.isImageParser());
- PARSER.parse(1);
- res = samp.sample();
- res.setSampleLabel(samp.toString());
-</pre>
-</code>
+<source>
+samp = (HTTPSampler) GENERATOR.generateRequest();
+samp.setDomain(this.getDomain());
+samp.setPort(this.getPort());
+samp.setImageParser(this.isImageParser());
+PARSER.parse(1);
+res = samp.sample();
+res.setSampleLabel(samp.toString());
+</source>
The required methods in LogParser are:
<ul>
<li>setGenerator(Generator)</li>
@@ -1687,42 +1685,51 @@ completed, so the net effect was similar
The current implementation supports standard Junit convention and extensions.
It also
includes extensions like oneTimeSetUp and oneTimeTearDown. The sampler works
like the
JavaSampler with some differences.
-<br></br>1. rather than use Jmeter's test interface, it scans the jar files
for classes extending junit's TestCase class. That includes any class or
subclass.
-<br></br>2. Junit test jar files should be placed in jmeter/lib/junit instead
of /lib directory.
-In versions of JMeter after 2.3.1, you can also use the "user.classpath"
property to specify where to look for TestCase classes.
-<br></br>3. Junit sampler does not use name/value pairs for configuration like
the JavaSampler. The sampler assumes setUp and tearDown will configure the test
correctly.
-<br></br>4. The sampler measures the elapsed time only for the test method and
does not include setUp and tearDown.
-<br></br>5. Each time the test method is called, Jmeter will pass the result
to the listeners.
-<br></br>6. Support for oneTimeSetUp and oneTimeTearDown is done as a method.
Since Jmeter is multi-threaded, we cannot call oneTimeSetUp/oneTimeTearDown the
same way Maven does it.
-<br></br>7. The sampler reports unexpected exceptions as errors.
+<ul>
+<li>rather than use Jmeter's test interface, it scans the jar files for
classes extending junit's TestCase class. That includes any class or
subclass.</li>
+<li>Junit test jar files should be placed in jmeter/lib/junit instead of /lib
directory.
+In versions of JMeter after 2.3.1, you can also use the "user.classpath"
property to specify where to look for TestCase classes.</li>
+<li>Junit sampler does not use name/value pairs for configuration like the
JavaSampler. The sampler assumes setUp and tearDown will configure the test
correctly.</li>
+<li>The sampler measures the elapsed time only for the test method and does
not include setUp and tearDown.</li>
+<li>Each time the test method is called, Jmeter will pass the result to the
listeners.</li>
+<li>Support for oneTimeSetUp and oneTimeTearDown is done as a method. Since
Jmeter is multi-threaded, we cannot call oneTimeSetUp/oneTimeTearDown the same
way Maven does it.</li>
+<li>The sampler reports unexpected exceptions as errors.
There are some important differences between standard JUnit test runners and
JMeter's
implementation. Rather than make a new instance of the class for each test,
JMeter
creates 1 instance per sampler and reuses it.
-This can be changed with checkbox "Create a new instance per sample".<br></br>
-The current implementation of the sampler will try to create an instance using
the string constructor first. If the test class does not declare a string
constructor, the sampler will look for an empty constructor. Example
below:<br>
-<br>
-Empty Constructor:<br>
-public class myTestCase {<br>
- public myTestCase() {}<br>
-}<br>
-<br>
-String Constructor:<br>
-public class myTestCase {<br>
- public myTestCase(String text) {<br>
- super(text);<br>
- }<br>
-}<br>
-By default, Jmeter will provide some default values for the success/failure
code and message. Users should define a set of unique success and failure codes
and use them uniformly across all tests.<br>
-General Guidelines<br></br>
+This can be changed with checkbox "Create a new instance per sample".</li>
+</ul>
+The current implementation of the sampler will try to create an instance using
the string constructor first. If the test class does not declare a string
constructor, the sampler will look for an empty constructor. Example below:
+<example title="Junit Constructors" anchor="junit_constructor_example">
+Empty Constructor:
+<pre>
+public class myTestCase {
+ public myTestCase() {}
+}
+</pre>
+String Constructor:
+<pre>
+public class myTestCase {
+ public myTestCase(String text) {
+ super(text);
+ }
+}
+</pre>
+</example>
+By default, Jmeter will provide some default values for the success/failure
code and message. Users should define a set of unique success and failure codes
and use them uniformly across all tests.
+<note>
+<h3>General Guidelines</h3>
If you use setUp and tearDown, make sure the methods are declared public. If
you do not, the test may not run properly.
<br></br>
-Here are some general guidelines for writing Junit tests so they work well
with Jmeter. Since Jmeter runs multi-threaded, it is important to keep certain
things in mind.<br>
-<br>
-1. Write the setUp and tearDown methods so they are thread safe. This
generally means avoid using static memebers.<br>
-2. Make the test methods discrete units of work and not long sequences of
actions. By keeping the test method to a descrete operation, it makes it easier
to combine test methods to create new test plans.<br>
-3. Avoid making test methods depend on each other. Since Jmeter allows
arbitrary sequencing of test methods, the runtime behavior is different than
the default Junit behavior.<br>
-4. If a test method is configurable, be careful about where the properties are
stored. Reading the properties from the Jar file is recommended.<br>
-5. Each sampler creates an instance of the test class, so write your test so
the setup happens in oneTimeSetUp and oneTimeTearDown.
+Here are some general guidelines for writing Junit tests so they work well
with Jmeter. Since Jmeter runs multi-threaded, it is important to keep certain
things in mind.
+<ul>
+<li>Write the setUp and tearDown methods so they are thread safe. This
generally means avoid using static memebers.</li>
+<li>Make the test methods discrete units of work and not long sequences of
actions. By keeping the test method to a descrete operation, it makes it easier
to combine test methods to create new test plans.</li>
+<li>Avoid making test methods depend on each other. Since Jmeter allows
arbitrary sequencing of test methods, the runtime behavior is different than
the default Junit behavior.</li>
+<li>If a test method is configurable, be careful about where the properties
are stored. Reading the properties from the Jar file is recommended.</li>
+<li>Each sampler creates an instance of the test class, so write your test so
the setup happens in oneTimeSetUp and oneTimeTearDown.</li>
+</ul>
+</note>
</description>
<properties>
<property name="Name" required="">Descriptive name for this element that is
shown in the tree.</property>
