Stub Driver

[email protected]

WR testing Process - 6 steps WR running the scripts 3 types WR recording modes WR GUI map 2 types WR Checkpoints 3 types(in detail) WR Exception Handlings 2 types (i hope, object & bitmap) WR Break Points WR Commands WR File comparision, srting comparision, string in a file comparision WR data driven wizard & comments inserted due to this WR commands for clicking button, editing the text, selecting the list items, status of buttons (enable, disable, focussed, non focussed) WR Scripting for verifying an image (Use Case: enter the path/select from the list, image is displayed on the same window, verify the image) WR Advantages & disadvantages WR running a script - 3 ways step, step in, step out WR Test results, format WR database- connecting, fetching a row, counting rows/columns, closing the connection, 2 types of db (ODBC & Data Junction) WR printing the messages WR Testing Concepts Testing techniques 2 type and explain them in brief Testing types - unit, integration, system, smoke, performance...etc SDLC min 3 type & 1 to explain in detail(Waterfall, spiral, V model) Bug life cycle CMM Level in brief Usability

Hello Vidya... Thanks for excellent reply. The example given really precise the definition. Will be grateful if you can clear bit more on this. Actually i have some contradict queries. Can i ping you in id (You need to give me) to clear my doubts. My ID: [email protected] Best Regds Manas Patra vidya kulkarni cc: Sent by: Subject: RE: [TESTINGKINGS] [Help] Difference between stubs and Testingkings@yahoo drivers....ASAP groups.com 08/02/2006 06:27 AM Please respond to Testingkings Hi, While doing integration testing,if we do not have all the modules available which are required for testing then we use stubs and drivers. Basically stubs and drivers are the piese of code that simulate the activity of missing modules. For eg: If you have module X and calls functions from module Y and Z.And you asked to test module X but Yand Z modules are not available to you. Then you need to come up with some sort of dummy code to mimick module Yand Z.This dummy piece of code is called stub. So stubs are "called functions" used in Top-Down Integration Testing.

Similar to above example,Now if you have Y and Z modules are available But X module is not availble and asked to test Yand Z modules. Now you need to come up with some dummy code to drive Yand Z.This piece of code is called driver. So drivers are "calling functions" used in Bottom -Up integration Testing. Rgds Vidya "Gunasekaran, Sureshkumar" <[email protected]> wrote: Hi, Stubs In Top? Down integration testing we use dummy modules to do the integration testing. Those dummy modules are called as stubs Drivers In Bottom? Down integration testing we use dummy modules to do the integration testing. Those dummy modules are called as drivers. For more detail Stubs and Drivers A software application is made up of a number of 'Units', where output of one 'Unit' goes as an 'Input' of another Unit. e.g. A 'Sales Order Printing' program takes a 'Sales Order' as an input, which is actually an output of 'Sales Order Creation' program. Due to such interfaces, independent testing of a Unit becomes impossible. But that is what we want to do; we want to test a Unit in isolation! So here we use 'Stub' and 'Driver. A 'Driver' is a piece of software that drives (invokes) the Unit being tested. A driver creates necessary 'Inputs' required for the Unit and then invokes the Unit. A Unit may reference another Unit in its logic. A 'Stub' takes place of such subordinate unit during the Unit Testing. A 'Stub' is a piece of software that works similar to a unit which is referenced by the Unit being tested, but it is much simpler that the actual unit. A Stub works as a 'Stand-in' for the subordinate unit and provides the minimum required behavior for that unit. Programmer needs to create such 'Drivers' and 'Stubs' for carrying out Unit Testing.

Both the Driver and the Stub are kept at a minimum level of complexity, so that they do not induce any errors while testing the Unit in question. Example - For Unit Testing of 'Sales Order Printing' program, a 'Driver' program will have the code which will create Sales Order records using hard coded data and then call 'Sales Order Printing' program. Suppose this printing program uses another unit which calculates Sales discounts by some complex calculations. Then call to this unit will be replaced by a 'Stub', which will simply return fix discount data. Integration testing is to test the data flow between the two modules, If the data flow between the two modules is ok than integration test pass. Types of integration 1.Top down 2.Bottom-up 3 Umberila approach (Big-Bang Approach) Do u have the description of Big-Bang Approach? No. But it’s nothing but combination of Top down& Bottom up approach.... Where all the modules are integrated at a time... & tested.... Test Life Cycle: 1.Understding Requirement (SRS, BRS, BDD etc) 2.Writing the Test cases. 3.Review the Test Cases 4.Execute the Test Cases 5.Defect Tracking 6.Regression Testing 7.Test Report.