ECSE-429 Project Fall 2020 Semester
ECSE Software Validation Term Project
Part C Non-Functional Testing of Rest API
Two types of non-functional testing will be implemented in part C of the project. Performance Testing using Dynamic Analysis and Static Analysis of the source code.
Performance Testing
Create a program which adds a specific number of to-dos, contexts, or projects. Populate these objects with random data.
Modify unit test scripts to log time T1 from beginning to end of test including assessing correctness, set up and restore activities, and time T2 which is the time of the transaction being tested but without set up, tear down and assessing correctness. Log the real time of each sample.
Perform the following experiments:
o As the number of to-dos increase measure the time to add, delete or change a to do.
o As the number of projects increase measure the time to add, delete or change a project. o As the number of contexts increase measure the time to add, delete or change a context.
Use operating system tools or open source tools to track CPU percent use and Available Free Memory while each experiment takes place, again log this information with the real time of the sample.
Operating system tools that may support dynamic analysis include:
Windows perfmon
Mac Activity Monitor
Linux vmstat
Static Analysis
The source code of the Rest API to do list manager will be studied with the community edition of the Sonar Cube static analysis tool.
https://www.sonarqube.org/downloads/
Recommendations should be made regarding changes to the source code to minimize risk during future modifications, enhancements, or bug fixes. Teams should look at code complexity, code statement counts, and any technical risks, technical debt or code smells highlighted by the static analysis.
Performance Test Suite Video
Show video of all performance tests running in the teams selected development environment.
Written Report
Target report size is between 5 and 10 pages. Summarizes deliverables.
Describes implementation of performance test suite.
1
ECSE-429 Project Fall 2020 Semester
Include excel charts showing transaction time, memory use and cpu us versus sample time for each experiment.
Include excel charts showing transaction time, memory use and cpu us versus number of objects for each experiment.
Summarize any recommendations for code enhancements related to results of performance testing.
Highlight any observed performance risks.
Describes implementation of static analysis with Sonar Cube community edition. Include recommendations for improving code based on the result of the static analysis.
2
ECSE-429 Project Fall 2020 Semester
Summary of clean code guidelines from Bob Martin.
Understandability tips
o Be consistent. If you do something a certain way, do all similar things in the same way.
o Useexplanatoryvariables.
o Encapsulate boundary conditions. Boundary conditions are hard to keep track of. Put the
processing for them in one place.
o Prefer dedicated value objects to primitive type.
o Avoidlogicaldependency.Don’twritemethodswhichworkscorrectlydependingonsomething
else in the same class.
o Avoidnegativeconditionals.
Names rules
o Choose descriptive and unambiguous names. o Make meaningful distinction.
o Usepronounceablenames.
o Use searchable names.
o Replace magic numbers with named constants.
o Avoidencodings.Don’tappendprefixesortypeinformation.
Functions rules
o Small.
o Doonething.
o Usedescriptivenames.
o Prefer fewer arguments.
o Havenosideeffects.
o Don’t use flag arguments. Split method into several independent methods that can be called
from the client without the flag. Comments rules
o Always try to explain yourself in code. o Don’tberedundant.
o Don’t add obvious noise.
o Don’tuseclosingbracecomments.
o Don’t comment out code. Just remove. o Use as explanation of intent.
o Use as clarification of code.
o Use as warning of consequences.
3
ECSE-429 Project Fall 2020 Semester Source code structure
o Separateconceptsvertically.
o Related code should appear vertically dense.
o Declare variables close to their usage.
o Dependent functions should be close.
o Similar functions should be close.
o Place functions in the downward direction.
o Keep lines short.
o Don’tusehorizontalalignment.
o Use white space to associate related things and disassociate weakly related.
o Don’tbreakindentation.
o Objects and data structures
o Hide internal structure.
o Prefer data structures.
o Avoid hybrids structures (half object and half data).
o Shouldbesmall.
o Doonething.
o Small number of instance variables.
o Base class should know nothing about their derivatives.
o Better to have many functions than to pass some code into a function to select a behavior. o Prefer non-static methods to static methods.
Tests
o One assert per test. o Readable.
o Fast.
o Independent.
o Repeatable. Avoid Code smells
o Rigidity. The software is difficult to change. A small change causes a cascade of subsequent changes.
o Fragility. The software breaks in many places due to a single change.
o Immobility. You cannot reuse parts of the code in other projects because of involved risks and
high effort.
o NeedlessComplexity.
o NeedlessRepetition.
o Opacity.Thecodeishardtounderstand.
4