You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@jmeter.apache.org by fs...@apache.org on 2015/06/06 16:41:33 UTC
svn commit: r1683916 - in /jmeter/trunk/xdocs: changes_history.xml
usermanual/component_reference.xml
Author: fschumacher
Date: Sat Jun 6 14:41:32 2015
New Revision: 1683916
URL: http://svn.apache.org/r1683916
Log:
Be consistent with spelling of JUnit.
Modified:
jmeter/trunk/xdocs/changes_history.xml
jmeter/trunk/xdocs/usermanual/component_reference.xml
Modified: jmeter/trunk/xdocs/changes_history.xml
URL: http://svn.apache.org/viewvc/jmeter/trunk/xdocs/changes_history.xml?rev=1683916&r1=1683915&r2=1683916&view=diff
==============================================================================
--- jmeter/trunk/xdocs/changes_history.xml (original)
+++ jmeter/trunk/xdocs/changes_history.xml Sat Jun 6 14:41:32 2015
@@ -3054,7 +3054,7 @@ httpclient3.retrycount=3
<li><bugzilla>51821</bugzilla> - Add short-cut for Enabling / Disabling (sub)tree or branches in test plan.</li>
<li><bugzilla>47921</bugzilla> - Variables not released for GC after JMeterThread exits.</li>
<li><bugzilla>51839</bugzilla> - "... end of run" printed prematurely</li>
-<li><bugzilla>51847</bugzilla> - Some Junit tests are Locale sensitive and fail if Locale is different from US</li>
+<li><bugzilla>51847</bugzilla> - Some JUnit tests are Locale sensitive and fail if Locale is different from US</li>
<li><bugzilla>51855</bugzilla> - Parent samples may have slightly inaccurate elapsed times</li>
<li><bugzilla>51880</bugzilla> - The shutdown command is not working if I invoke it before all the thread are started</li>
<li>Remote Shut host menu item was not being enabled.</li>
Modified: jmeter/trunk/xdocs/usermanual/component_reference.xml
URL: http://svn.apache.org/viewvc/jmeter/trunk/xdocs/usermanual/component_reference.xml?rev=1683916&r1=1683915&r2=1683916&view=diff
==============================================================================
--- jmeter/trunk/xdocs/usermanual/component_reference.xml (original)
+++ jmeter/trunk/xdocs/usermanual/component_reference.xml Sat Jun 6 14:41:32 2015
@@ -1728,14 +1728,14 @@ completed, so the net effect was similar
<component name="JUnit Request" index="§-num;.1.16" width="397" height="536" screenshot="junit_sampler.png">
<description>
-The current implementation supports standard Junit convention and extensions. It also
+The current implementation supports standard JUnit convention and extensions. It also
includes extensions like <code>oneTimeSetUp</code> and <code>oneTimeTearDown</code>. The sampler works like the
<complink name="Java Request" /> with some differences.
<ul>
-<li>rather than use Jmeter's test interface, it scans the jar files for classes extending junit's <code>TestCase</code> class. That includes any class or subclass.</li>
-<li>Junit test jar files should be placed in <code>jmeter/lib/junit</code> instead of <code>/lib</code> directory.
+<li>rather than use Jmeter's test interface, it scans the jar files for classes extending JUnit's <code>TestCase</code> class. That includes any class or subclass.</li>
+<li>JUnit test jar files should be placed in <code>jmeter/lib/junit</code> instead of <code>/lib</code> directory.
In versions of JMeter after 2.3.1, you can also use the "<code>user.classpath</code>" property to specify where to look for <code>TestCase</code> classes.</li>
-<li>Junit sampler does not use name/value pairs for configuration like the <complink name="Java Request" />. The sampler assumes <code>setUp</code> and <code>tearDown</code> will configure the test correctly.</li>
+<li>JUnit sampler does not use name/value pairs for configuration like the <complink name="Java Request" />. The sampler assumes <code>setUp</code> and <code>tearDown</code> will configure the test correctly.</li>
<li>The sampler measures the elapsed time only for the test method and does not include <code>setUp</code> and <code>tearDown</code>.</li>
<li>Each time the test method is called, Jmeter will pass the result to the listeners.</li>
<li>Support for <code>oneTimeSetUp</code> and <code>oneTimeTearDown</code> is done as a method. Since Jmeter is multi-threaded, we cannot call <code>oneTimeSetUp</code>/<code>oneTimeTearDown</code> the same way Maven does it.</li>
@@ -1746,7 +1746,7 @@ creates 1 instance per sampler and reuse
This can be changed with checkbox "<code>Create a new instance per sample</code>".</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">
+<example title="JUnit Constructors" anchor="junit_constructor_example">
Empty Constructor:
<source>
public class myTestCase {
@@ -1767,11 +1767,11 @@ By default, Jmeter will provide some def
<h3>General Guidelines</h3>
If you use <code>setUp</code> and <code>tearDown</code>, 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.
+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 <code>setUp</code> and <code>tearDown</code> methods so they are thread safe. This generally means avoid using static members.</li>
<li>Make the test methods discrete units of work and not long sequences of actions. By keeping the test method to a discrete 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>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 <code>oneTimeSetUp</code> and <code>oneTimeTearDown</code>.</li>
</ul>