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


 One Stop Testing ForumTypes Of Software Testing @ OneStopTestingUnit Testing @ OneStopTesting

Message Icon Topic: Unit Testing with Mock Objects

Post Reply Post New Topic
Author Message
Sunil
Newbie
Newbie


Joined: 23Feb2007
Online Status: Offline
Posts: 1
Quote Sunil Replybullet Topic: Unit Testing with Mock Objects
    Posted: 23Feb2007 at 4:36pm
Unit testing is a fundamental practice in Extreme Programming [Beck 1999], but most nontrivial
code is difficult to test in isolation. You need to make sure that you test one feature at a
time, and you want to be notified as soon as any problem occurs. Normal unit testing is hard
because you are trying to test the code from outside.
We propose a technique called Mock Objects in which we replace domain code with dummy
implementations that emulate real code. These Mock Objects are passed to the target domain
code which they test from inside, hence the term Endo-Testing. This practice is similar to
writing code stubs with two interesting differences: we test at a finer level of granularity than
is usual, and we use our tests and stubs to drive the development of our production code.
Our experience is that developing unit tests with Mock Objects leads to stronger tests and to
better structure of both domain and test code. Unit tests written with Mock Objects have a
regular format that gives the development team a common vocabulary. We believe that code
should be written to make it easy to test, and have found that Mock Objects is a good
technique to achieve this. We have also found that refactoring Mock Objects drives down the
cost of writing stub code.

Unit testing with Mock Objects
An essential aspect of unit testing is to test one feature at time; you need to know exactly what
you are testing and where any problems are. Test code should communicate its intent as
simply and clearly as possible. This can be difficult if a test has to set up domain state or the

domain code causes side effects. Worse, the domain code might not even expose the features
to allow you to set the state necessary for a test.
For example, the authors have written tools to extend the development environment in IBM’s
VisualAge for Java, one of which generates template classes. This tool should not write a new
template class if one already exists in the environment. A naïve unit test for this requirement
would create a known class, attempt to generate a template class with the same name, and
then check that the known class has not changed. In VisualAge this raises incidental issues
such as whether the known class has been set up properly, ensuring that the user has the right
permissions, and cleaning up after the test should it fail – none of which are relevant to the
test.



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.078 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