Active TopicsActive Topics  Display List of Forum MembersMemberlist  CalendarCalendar  Search The ForumSearch  HelpHelp
  RegisterRegister  LoginLogin


 One Stop Testing ForumSoftware Testing @ OneStopTestingTest Cases @ OneStopTesting

Message Icon Topic: TestCase Objects

Post Reply Post New Topic
Author Message
tanushree
Senior Member
Senior Member
Avatar

Joined: 04Apr2007
Online Status: Offline
Posts: 2160
Quote tanushree Replybullet Topic: TestCase Objects
    Posted: 29Oct2007 at 3:24am

TestCase Objects:


Each TestCase instance represents a single test, but each concrete subclass may be used to define multiple tests -- the concrete class represents a single test fixture. The fixture is created and cleaned up for each test case.

TestCase instances provide three groups of methods: one group used to run the test, another used by the test implementation to check conditions and report failures, and some inquiry methods allowing information about the test itself to be gathered.

Methods in the first group (running the test) are:

setUp( )
Method called to prepare the test fixture. This is called immediately before calling the test method; any exception raised by this method will be considered an error rather than a test failure. The default implementation does nothing.

tearDown( )
Method called immediately after the test method has been called and the result recorded. This is called even if the test method raised an exception, so the implementation in subclasses may need to be particularly careful about checking internal state. Any exception raised by this method will be considered an error rather than a test failure. This method will only be called if the setUp() succeeds, regardless of the outcome of the test method. The default implementation does nothing.

run( [result])
Run the test, collecting the result into the test result object passed as result. If result is omitted or None, a temporary result object is created (by calling the defaultTestCase() method) and used; this result object is not returned to run()'s caller.

The same effect may be had by simply calling the TestCase instance.

debug( )
Run the test without collecting the result. This allows exceptions raised by the test to be propagated to the caller, and can be used to support running tests under a debugger.

The test code can use any of the following methods to check for and report failures.

assert_( expr[, msg])

failUnless( expr[, msg])
Signal a test failure if expr is false; the explanation for the error will be msg if given, otherwise it will be None.

assertEqual( first, second[, msg])

failUnlessEqual( first, second[, msg])
Test that first and second are equal. If the values do not compare equal, the test will fail with the explanation given by msg, or None. Note that using failUnlessEqual() improves upon doing the comparison as the first parameter to failUnless(): the default value for msg can be computed to include representations of both first and second.

assertNotEqual( first, second[, msg])

failIfEqual( first, second[, msg])
Test that first and second are not equal. If the values do compare equal, the test will fail with the explanation given by msg, or None. Note that using failIfEqual() improves upon doing the comparison as the first parameter to failUnless() is that the default value for msg can be computed to include representations of both first and second.

assertAlmostEqual( first, second[, places[, msg]])

failUnlessAlmostEqual( first, second[, places[, msg]])
Test that first and second are approximately equal by computing the difference, rounding to the given number of places, and comparing to zero. Note that comparing a given number of decimal places is not the same as comparing a given number of significant digits. If the values do not compare equal, the test will fail with the explanation given by msg, or None.

assertNotAlmostEqual( first, second[, places[, msg]])

failIfAlmostEqual( first, second[, places[, msg]])
Test that first and second are not approximately equal by computing the difference, rounding to the given number of places, and comparing to zero. Note that comparing a given number of decimal places is not the same as comparing a given number of significant digits. If the values do not compare equal, the test will fail with the explanation given by msg, or None.

assertRaises( exception, callable, ...)

failUnlessRaises( exception, callable, ...)
Test that an exception is raised when callable is called with any positional or keyword arguments that are also passed to assertRaises(). The test passes if exception is raised, is an error if another exception is raised, or fails if no exception is raised. To catch any of a group of exceptions, a tuple containing the exception classes may be passed as exception.

failIf( expr[, msg])
The inverse of the failUnless() method is the failIf() method. This signals a test failure if expr is true, with msg or None for the error message.

fail( [msg])
Signals a test failure unconditionally, with msg or None for the error message.

failureException
This class attribute gives the exception raised by the test()AssertionError. method. If a test framework needs to use a specialized exception, possibly to carry additional information, it must subclass this exception in order to ``play fair'' with the framework. The initial value of this attribute is

Testing frameworks can use the following methods to collect information on the test:

countTestCases( )
Return the number of tests represented by this test object. For TestCase instances, this will always be 1.

defaultTestResult( )
Return an instance of the test result class that should be used for this test case class (if no other result instance is provided to the run() method).

For TestCase instances, this will always be an instance of TestResult; subclasses of TestCase should override this as necessary.

id( )
Return a string identifying the specific test case. This is usually the full name of the test method, including the module and class name.

shortDescription( )
Returns a one-line description of the test, or None if no description has been provided. The default implementation of this method returns the first line of the test method's docstring, if available, or None.





Post Resume: Click here to Upload your Resume & Apply for Jobs

IP IP Logged
Post Reply Post New Topic
Printable version Printable version

Forum Jump
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot delete your posts in this forum
You cannot edit your posts in this forum
You cannot create polls in this forum
You cannot vote in polls in this forum



This page was generated in 0.187 seconds.
Vyom is an ISO 9001:2000 Certified Organization

© Vyom Technosoft Pvt. Ltd. All Rights Reserved.

Privacy Policy | Terms and Conditions
Job Interview Questions | Placement Papers | Free SMS | Freshers Jobs | MBA Forum | Learn SAP | Web Hosting