You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@jmeter.apache.org by pm...@apache.org on 2017/08/30 12:15:51 UTC
svn commit: r1806691 - /jmeter/trunk/xdocs/usermanual/component_reference.xml
Author: pmouawad
Date: Wed Aug 30 12:15:50 2017
New Revision: 1806691
URL: http://svn.apache.org/viewvc?rev=1806691&view=rev
Log:
Use JMeter instead of Jmeter.
Clarify timing for JUnit as it seems it is not as per:
- https://stackoverflow.com/questions/45959941/calculate-time-of-execution-of-junit-test-in-jmeter-without-setup-and-teardown-m/
Modified:
jmeter/trunk/xdocs/usermanual/component_reference.xml
Modified: jmeter/trunk/xdocs/usermanual/component_reference.xml
URL: http://svn.apache.org/viewvc/jmeter/trunk/xdocs/usermanual/component_reference.xml?rev=1806691&r1=1806690&r2=1806691&view=diff
==============================================================================
--- jmeter/trunk/xdocs/usermanual/component_reference.xml (original)
+++ jmeter/trunk/xdocs/usermanual/component_reference.xml Wed Aug 30 12:15:50 2017
@@ -1712,16 +1712,16 @@ public class myTestCase {
}
</source>
</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.
+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 <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>
@@ -1761,6 +1761,7 @@ The following JUnit4 annotations are rec
<note>
Note that JMeter currently runs the test methods directly, rather than leaving it to JUnit.
This is to allow the <code>setUp</code>/<code>tearDown</code> methods to be excluded from the sample time.
+As a consequence, the sampler time excludes the time taken to call setUp/tearDown methods.
</note>
</component>
Re: svn commit: r1806691 - /jmeter/trunk/xdocs/usermanual/component_reference.xml
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 30. August 2017 14:15:51 MESZ schrieb pmouawad@apache.org:
>Author: pmouawad
>Date: Wed Aug 30 12:15:50 2017
>New Revision: 1806691
>
>URL: http://svn.apache.org/viewvc?rev=1806691&view=rev
>Log:
>Use JMeter instead of Jmeter.
>Clarify timing for JUnit as it seems it is not as per:
>
>-
>https://stackoverflow.com/questions/45959941/calculate-time-of-execution-of-junit-test-in-jmeter-without-setup-and-teardown-m/
>
>Modified:
> jmeter/trunk/xdocs/usermanual/component_reference.xml
>
>Modified: jmeter/trunk/xdocs/usermanual/component_reference.xml
>URL:
>http://svn.apache.org/viewvc/jmeter/trunk/xdocs/usermanual/component_reference.xml?rev=1806691&r1=1806690&r2=1806691&view=diff
>==============================================================================
>--- jmeter/trunk/xdocs/usermanual/component_reference.xml (original)
>+++ jmeter/trunk/xdocs/usermanual/component_reference.xml Wed Aug 30
>12:15:50 2017
>@@ -1712,16 +1712,16 @@ public class myTestCase {
> }
> </source>
> </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.
>+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 <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
You missed one Jmeter conversion :)
>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>
>@@ -1761,6 +1761,7 @@ The following JUnit4 annotations are rec
> <note>
>Note that JMeter currently runs the test methods directly, rather than
>leaving it to JUnit.
>This is to allow the <code>setUp</code>/<code>tearDown</code> methods
>to be excluded from the sample time.
>+As a consequence, the sampler time excludes the time taken to call
>setUp/tearDown methods.
setUp and tearDown could be marked up like the rest occurrences.
Felix
> </note>
> </component>
>