Static testing

Elena Rudovol
February, 13, 2014

Sitecore. Compelling Web Experiences

What is static testing?

Static Testingdo not execute code.

Review work documents:

It manually checks work documents to find errors in early stage.

Requirement specifications
Design document
Source Code
Test Plans
Test Cases
Test Scripts
Help or User document
Web Page content

Static Testing Techniques (ISTQB):

Individual:
- desk-checking, data-stepping, proof-reading
Group:
- Reviews (informal & formal): for consensus
- Walkthrough (guide a group): for education
- Inspection (most formal): to find faults

www.sitecore.net

Page 2

Sitecore. Compelling Web Experiences

Static VS dynamic testing

Note: Both types of testing are important.

Static testing

Dynamic testing

Without executing the program

By executing the program

Verification process

Validation process

Prevention of defects

Finding and fixing the defects

Evaluates code/documentation

Finds dugs/bottlenecks in the system

Cost of defect is less

Cost of defect is high

Return on investment will be high (early stage)

Return on investment will be low (after development

phase)

www.sitecore.net

Page 3

Sitecore. Compelling Web Experiences

Requirements specification review

Most of the bugs in software are due to incomplete or
inaccurate functional requirements
Requirements:

should be clear and specific with no uncertainty,

should be testable having some evaluation criteria for each requirement,

should be related to project goal,

should be measurable in terms of specific values (e.g. response in 2 seconds instead of
works fast),
should be complete and consistent, without any duplicates and missing requirements

Good practices:

Write good-structured requirements or user stories (easy-to-find),

Supplement with examples of scenarios how to use a system,

BDD is a good approach for writing good specification. It includes all best
practices above.

Use techniques of model-based testing in requirements (decision tables, state transition

diagrams),

www.sitecore.net

Page 4

Sitecore. Compelling Web Experiences

Why do we need manual code review?

Knowledge sharing:

Easier to make bug-fix

Easier to get started for newcomers
Easier to support the code

Less work in the future:

Less amount of mistakes

Less time to understand the code
Easier to support the code

Adoption:

Frequently changed requirements require fast adoption to them

www.sitecore.net

Page 5

Sitecore. Compelling Web Experiences

Manual code review

Main goals:
Finding potential bugs on the cheap:

obvious mistakes,

mistakes that difficult to find after-the-fact (e.g. thread synchronization, resource leaks etc.),

ensuring that unit tests cover all code paths,

Well-documented software:

consistent end-user documentation (Its important for Sitecore to provide well-documented API!),

adequate comments in code,

Software that complies with enterprise coding standards:

following code standards and OOP practices,

no anti-patterns in code and database structure,

Teaching and sharing knowledge between developers.

Good practices:

review can to be done by any team member (not only lead developer),
add a status Ready for Review into bug-tracking system.

www.sitecore.net

Page 6

Sitecore. Compelling Web Experiences

Main metrics in Sonar

Code coverage - % of code which is covered by unit tests:
Line Coverage - % of rows which run and tested (e.g. 80%)
Branch coverage - % of conditionals (true/false) run and tested (e.g. 80%)
Branch coverage is more important because it shows real coverage of business logic

Comments in code:
API should be well documented (feedback from marketing department)
tools for comments generating (e.g. GhostDoc, Doxygen)
most public methods should be documented (E.g. metric is 80%)
no commented rows in code
Duplications:
We should achieve 0% of copy-paste in code.

Violations:
We should pay attention on Sonar violations and fix blockers, critical and major.

www.sitecore.net

Page 7

Sitecore. Compelling Web Experiences

LCOM4 metric
Lack of Cohesion of Methods (LCOM4) metric:
The more cohesion the higher probability to fail if functionality is changed.
Good LCOM4 example:
public class ClientData
{
public string FirstName;
public string LastName;

Bad LCOM4 example:

public class Client
{
public string FirstName;
public string LastName;
public string Street;
public string City;
public string ZipCode;

public string GetFullName()

{
return this.FirstName + " " + this.LastName;
}
}

public string GetFullName()

{
return this.FirstName + " " + this.LastName;
}
public string GetFullAddress()
{
return this.Street + " " + this.City + " " + this.ZipCode;
}

public class ClientAddress

{
public string Street;
public string City;
public string ZipCode;
public string GetFullAddress()
{
return this.Street + " " + this.City + " " + this.ZipCode;
}

}
}

www.sitecore.net

Page 8

Sitecore. Compelling Web Experiences

Package tangle index metric

Package tangle index:
Dependencies should flow in one direction. No cyclomatic dependencies.
Example:

UI

Business
logic

www.sitecore.net

Database

Page 9

Sitecore. Compelling Web Experiences

Code complexity
The complexity is measured by the number of if, while, do, for, ?:, catch, switch, case statements,
and operators && and || (plus one) in the body of a constructor, method, static initializer, or instance
initializer.

Complexity = number of decisions + 1.

E.g. Following flow has complexity 3.

Generally:
- up to 7 for method
- up to 15 for class

www.sitecore.net

Page 10

Sitecore. Compelling Web Experiences

Static Testing Techniques

Benefits of reviews:

Development productivity improvement

Reduced development timescales
Reduced testing time and cost
Lifetime cost reductions
Reduced fault levels
Improved customer relations etc.

www.sitecore.net

Page 11

Sitecore. Compelling Web Experiences

Code review in Sitecore

www.sitecore.net

Page 12

Sitecore. Compelling Web Experiences

Code review in Sitecore

Demo & questions

www.sitecore.net

Page 13