Presented By:

ABDUL MAJEED K.M

5ZD11SPZ01
4
TH
SEM CSE
M-Tech (PART TIME QIP)



CONTENTS
Introduction
Test-Driven Development
Refactoring
Causes of Refactoring
Test Case Code Smells
Test Code Refactoring
Conclusion
Reference


Computer software is an engine of growth of social economy
development which requires new techniques and strategies.
The unit test provides the lowest level of testing during software
development.
Automated Testing is the other program that runs the program
being tested, feeding it with proper input, and thus checking
the output against the expected.
INTRODUCTION (Continue.)
Adequate testing however, can be difficult if the
software is extremely large and complex.

Amongst different types of program transformation,
behavior-preserving source-to-source
transformations are known as refactoring .


TEST-DRIVEN DEVELOPMENT

It provides to guarantee testability to reach an
extremely high test coverage, to enhance developer
confidence, for highly cohesive and loosely coupled
systems, to allow larger teams of programmers to
work on the same code base, as the code can be
checked more often.
TEST-DRIVEN DEVELOPMENT( Continue.)
The TDD cycle consists of six fundamental steps:

1. Write a test for a piece of functionality,
2. Run all tests to see the new test to fail,
3. Write corresponding code that passes these tests,
4. Run the test to see all pass,
5. Refactor the code and
6. Run all tests to see the refactoring did not change the
external behavior.


TEST-DRIVEN DEVELOPMENT( Continue.)
REFACTORING

The Program restructuring is a technique for rewriting
software may be useful either for legacy software
as well as for the production of new systems.
Software evolution can be classified into the
following types:
Corrective evolution: correction of errors;
Adaptive evolution: modifications to accommodate
requirement changes;
Perfective evolution: modifications to enhance
existing features.

REFACTORING (Continue..)
Refactoring is mostly applied in perfective software
evolution, though it also affects corrective and
adaptive evolution.
A known issue about refactoring is automatization.
Small steps of refactoring have usually been
performed manually, using primitive tools such as
text editors

CAUSES OF REFACTORING
In computer programming, code smell is any
symptom in the source code of a program that
possibly indicates a problem at steep level.
Determining a code smell is often a subjective
judgment and will often vary by language,
developer and its methodology.
There are certain tools, such as Checkstyle and
FindBugs for Java, to automatically evaluate for
certain kinds of code smells.

CAUSES OF REFACTORING( Continue.)
Refactoring (to Patterns)
Simple Design -> Code Smell -> Refactor
Refactoring ( to Patterns) is the ability to transform a Code
Smell into a positive design pattern
Following are the examples of some of the Bad Code Smells
that are encountered in case (unit/class) design
Duplicated Code
Methods too big
Nested if statements
Classes with too many instance variables
Classes with too much code


















TEST CASE CODE SMELLS

Self Contained
When a test uses external resources, such as file
containing test data, the test is no longer self contained.
Resource Optimism
Test code that makes optimistic assumptions about the
existence and state of external resources can cause
nondeterministic behavior in test outcomes.
Resource Interface
Such wars arise when the tests execute you are the only
one testing which fails when more programmers run
them.


TEST CASE CODE SMELLS (Continue)
Setup Method
In the JUnit framework a programmer can write a
setUp method that can be executed before each test
method to create a fixture for the tests to run.
Splitting Method
When a test method checks methods of the object
to be tested, it is hard to read and understand, and
therefore more difficult to use as documentation.
Assertion Roulette
Guess whats wrong?

TEST CASE CODE SMELLS(Continue..)
Class-to-be-tested
A test class is supposed to test its counterpart in the
production code.
Duplication across Test Class
Test code may contain undesirable duplication.
TEST CODE REFACTORING
Bad smell seems to arise more often in production
code than in test code.
To maintain this freshness, test code also needs to be
refactored. We define test refactoring as changes of
test code that:
do not add or remove test cases, and
Make test code better understandable/ readable
and/or maintainable.

TEST CODE REFACTORING (Continue..)
While working on our test code, the following
refactorings are encountered:

Integral Resource
To remove the dependency between a test method and
some external resource, we incorporate the resource in the
test code.
Resource Allocation
If it is necessary for a test to rely on external resources,
such as directories, databases or files, make sure the test
that uses them explicitly creates or allocates these
resources before testing and releases them when done.
TEST CODE REFACTORING (Continue..)

Identified Uniquely
Lot of problems originate from the use of overlapping resource
names; either between different tests run done by the same user or
between simultaneous test runs done by different users.

Minimize Data
(1) in making them better suitable for documentation and
consequently
(2) the tests will be less sensitive to changes.

Assertion Explanation
Assertions in the JUnit framework have an optional first argument to
give an explanatory message to the user when the assertion fails.


Add Equality Method
If an object structure needs to be checked for equality in tests, an
implementation for the equals method for the objects class
needs to be added.
TEST CODE REFACTORING (Continue..)



CONCLUSION

The large refactoring can improve overall quality of a test case using
these set of smells choices.
The only concern needs to be understand the selection of refactoring
choices.
A software system essentially needs the refactoring systems for its
better performance.
Thus this refactoring process assist in its high quality and can prove to
be more maintainable techniques.
This refactoring process thus can be executed in lower error rates,
fewer test cases per module and to increase over all understandability
and maintainability in return.

REFERENCES

[1] Cohen M. B., P. B. Gibbons, W. B. Mugridge and C. J. Colbourn,Constructing
Test Suites for Interaction Testing. 25th International Conference on Software
Engineering (ICSE'30), Portland, Oregon,United States, IEEE Computer Society,
2003,38-49.
2] Don Roberts. Practical Analysis for Refactoring. (PhD thesis, University of
Illinois at Urbana-Champaign, 1999).
[3] Elbaum S., A. G. Malishevsky and G. Rothermel, Prioritizing Test Cases for
Regression Testing, ACM SIGSOFT International Symposium on Software Testing
and Analysis, Portland, Oregon, United States, ACM Press, 2000,102-112.
[4] Fodeh John A. and Niels B. Svendsen, Release Metrics : When to Stop Testing
with a clear conscience, Journal of Software Testing Professionals, March 2002.
[5] Fowler M. Refactoring: Improving the Design of Ex-isting Code(Addison-
Wesley, 1999).
[6] Griswold William G. Program Restructuring as an Aid to Software
Maintenance, (PhD thesis, University of Washington, 1991).

ANY QUESTION?????