Static Testing1

Static testingElena Rudovol

February, 13, 2014

Sitecore. Compelling Web Experiences

www.sitecore.net Page 2

What is static testing?

Static Testing do not execute code.

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

• 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



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)



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 related to project goal,

- should be measurable in terms of specific values (e.g. “response in 2 seconds” instead of “works fast”),

- should be testable having some evaluation criteria for each requirement,

- should be complete and consistent, without any duplicates and missing requirements

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

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

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.



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



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 (It’s 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.



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.



LCOM4 metric

Lack of Cohesion of Methods (LCOM4) metric:

The more cohesion the higher probability to fail if functionality is changed.

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 GetFullAddress()

{

return this.Street + " " + this.City + " " + this.ZipCode;

}

}

Good LCOM4 example:

public class ClientData

{

public string FirstName;

public string LastName;

public string GetFullName()

{

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

}

}

public class ClientAddress

{

public string Street;

public string City;

public string ZipCode;

public string GetFullAddress()

{

return this.Street + " " + this.City + " " + this.ZipCode;

}

}



Package tangle index metricPackage tangle index:

Dependencies should flow in one direction. No cyclomatic dependencies.

Example:

UI Business logic Database



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



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.



Code review in Sitecore



Code review in Sitecore

Demo & questions

Documents

Static Testing1