Unit Testing -- Data Driven Example - Revision history

Radiant tech: added Testing and Bug Squad categories

2011-12-15T19:52:57Z

added Testing and Bug Squad categories

Ian: /* Putting It All Together */

2008-12-07T21:00:38Z

‎Putting It All Together

Jwwicks: /* Building the Mock Class */ corrected a typo

2008-07-12T03:44:02Z

‎Building the Mock Class: corrected a typo

Instance at 23:02, 24 June 2008

2008-06-24T23:02:00Z

Instance: /* Defining a Data Set */ Added information on test versions.

2008-06-22T18:39:26Z

‎Defining a Data Set: Added information on test versions.

Instance at 12:54, 13 May 2008

2008-05-13T12:54:38Z

Instance: Move mock object info, cleanup.

2008-05-13T12:46:31Z

Move mock object info, cleanup.

Show changes

Instance: functionally complete, still needs editing for style and break-out of mock discussion.

2008-05-12T21:27:56Z

functionally complete, still needs editing for style and break-out of mock discussion.

Instance at 21:02, 12 May 2008

2008-05-12T21:02:57Z

Instance at 20:42, 12 May 2008

2008-05-12T20:42:24Z

← Older revision		Revision as of 19:52, 15 December 2011
Line 175:		Line 175:

	Return to [[Unit_Testing\|Unit Testing]]		Return to [[Unit_Testing\|Unit Testing]]
		+
		+	[[Category:Testing]][[Category:Bug Squad]]

← Older revision		Revision as of 21:00, 7 December 2008
Line 167:		Line 167:

	The setUp() method has initialized the super-globals already. We start by instantiating a mock JFilterInput object, resetting it, and then defining our expectations for it by calling mockSetUp() for each element in the $filterCalls array.		The setUp() method has initialized the super-globals already. We start by instantiating a mock JFilterInput object, resetting it, and then defining our expectations for it by calling mockSetUp() for each element in the $filterCalls array.
		+
		+	Don't forget to add a require_once above your class definition to include your helper class.

	Then we run the core of our test, calling once with the cache empty and one where there may be a cached value.		Then we run the core of our test, calling once with the cache empty and one where there may be a cached value.

@@ Line 13: / Line 13: @@
 The process of building a mock JFilterInput class for this test is discussed in detail in the [[Unit_Testing_Mock_Objects|Mock Objects in Joomla]] article. It's a good idea to have an understanding of this before proceeding.
-One the mock is defined, we replace the real JInputFilter class by injecting a mock just after the unit test platform is loaded:
+Once the mock is defined, we replace the real JInputFilter class by injecting a mock just after the unit test platform is loaded:
 <source lang="php">

← Older revision		Revision as of 23:02, 24 June 2008
Line 171:		Line 171:

	Finally, we call mockTearDown(). If this method returns true, then the mock was used as we expected. If not, we dump the details of the discrepancies while failing the test.		Finally, we call mockTearDown(). If this method returns true, then the mock was used as we expected. If not, we dump the details of the discrepancies while failing the test.
		+
		+	Return to [[Unit_Testing\|Unit Testing]]

← Older revision		Revision as of 18:39, 22 June 2008
Line 84:		Line 84:

	Some readers may be surprised when they don't find tests to verify that strings like '123abc' are not numeric. There are no tests like this because although this is the most common use of getVar(), the actual filtering is done by the JFilterInput class, so test cases like that belong with the JFilterInput tests. Our tests merely need to verify that the data is coming from the right place.		Some readers may be surprised when they don't find tests to verify that strings like '123abc' are not numeric. There are no tests like this because although this is the most common use of getVar(), the actual filtering is done by the JFilterInput class, so test cases like that belong with the JFilterInput tests. Our tests merely need to verify that the data is coming from the right place.
		+
		+	'''Specifying Version Restrictions'''
		+
		+	The test facility provides a standard mechanism for masking tests by version. You can add version restrictions to the data set as follows: "jver_min" specifies the minimum version; "jver_max" specifies the maximum version; and "jver_below" specifies defines an upper limit to the version.
		+
		+	Examples:
		+	<source lang="php">
		+	'jver_below' => '1.5.0' // Specifies any test in the 1.x series before the 1.5.0 release.
		+	'jver_max' => '1.5.4' // Specifies a test that will be disabled in versions 1.5.5 and above.
		+	'jver_min' => '1.6.0' // Specifies a test that will only be active on version 1.6.0 and above.
		+	</source>
		+
		+	For data-driven tests, these values will be stored as part of the data set. In your tests, use JUnit_Setup::isTestEnabled(JVERSION, $range) to determine if the test should be run.

	==== PHPUnit's Data Provider Mechanism ====		==== PHPUnit's Data Provider Mechanism ====

@@ Line 12: / Line 12: @@
 === Building the Mock Class ===
 The process of building a mock JFilterInput class for this test is discussed in detail in the [[Unit_Testing_Mock_Objects|Mock Objects in Joomla]] article. It's a good idea to have an understanding of this before proceeding.
 === A Unit Test for JRequest::getVar() ===

@@ Line 1: / Line 1: @@
 == Anatomy of a Data-Driven Test ==
 This expands on the basics given in (add link). In this example, we're interested in running a number of tests on the JRequest::getVar() method, each with different parameters. While it's possible to just write one test and then copy it once for each test, this would create a lot of duplicate code, add a lot of needless lines to the test file, and make it harder to organize test cases.
@@ Line 179: / Line 181: @@
 Some readers may be surprised when they don't find tests to verify that strings like '123abc' are not numeric. There are no tests like this because although this is the most common use of getVar(), the actual filtering is done by the JFilterInput class, so test cases like that belong with the JFilterInput tests. Our tests merely need to verify that the data is coming from the right place.

@@ Line 141: / Line 141: @@
 We check that we get the expected result, and we check that the cache works.
 ==== Defining a Data Set ====
@@ Line 148: / Line 161: @@
 * For some of these combinations, JRequest will use JInputFilter. In these cases we need to define the expected calls to our mock class, and the result.
-Sample data set entry:
+We define each of these tests in an array in our helper class, $getVarTests. Here is a sample entry:
 <source lang="php">
 		array(
@@ Line 157: / Line 170: @@
 		),
 </source>

@@ Line 11: / Line 11: @@
 === Building a Mock Class ===
+(ed note: this should be its own page)
 ==== Defining a Mock Class for JFilterInput ====
@@ Line 119: / Line 119: @@
 That's all we need to support our test for JRequest. Let's put it to use.
 Sample general-purpose mock: /unittest/tests/libraries/joomla/plugin/JPluginHelper-mock-general.php