1. Static testing Elena Rudovol February, 13, 2014

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

3. Sitecore. Compelling Web Experiences www.sitecore.net Page 3 Static VS dynamic testing Note: Both types of testing are important. Static testingDynamic testing Without executing the programBy executing the program Verification processValidation process Prevention of defectsFinding and fixing the defects Evaluates code/documentationFinds dugs/bottlenecks in the system Cost of defect is lessCost of defect is high Return on investment will be high (early stage)Return on investment will be low (after development phase)

4. Sitecore. Compelling Web Experiences www.sitecore.net Page 4 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.

5. Sitecore. Compelling Web Experiences www.sitecore.net Page 5 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

6. Sitecore. Compelling Web Experiences www.sitecore.net Page 6 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.

7. Sitecore. Compelling Web Experiences www.sitecore.net Page 7 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.

8. Sitecore. Compelling Web Experiences www.sitecore.net Page 8 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; }

9. Sitecore. Compelling Web Experiences www.sitecore.net Page 9 Package tangle index metric Package tangle index: Dependencies should flow in one direction. No cyclomatic dependencies. Example: UI Business logic Database

10. Sitecore. Compelling Web Experiences www.sitecore.net Page 10 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

11. Sitecore. Compelling Web Experiences www.sitecore.net Page 11 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.

12. Sitecore. Compelling Web Experiences www.sitecore.net Page 12 Code review in Sitecore

13. Sitecore. Compelling Web Experiences www.sitecore.net Page 13 Code review in Sitecore Demo & questions