Define Reliability
The reliability of a system is the degree to which observed behaviour conforms to its specification
What sort of things can we test - level of components?
We classify tests by the level of component or system they work with:
- We can test some code which is a small part of a larger system
○ For instance: a single procedure, method or function (this is unit testing)
- We can test how unit, classes, modules or other components of a system work together (this is called integration testing
- We can test an entire system (this is called system testing)
- We can test whether the system meets its specifications and whether it properly executes some scenario in an appropriate environment (this is end-to end testing)
What sort of things can we test - classified by purpose?
We can also classify them by the purpose of the test, or when in the software development lifecycle the testing activity occurs:
- After making a change to some component (an enhancement, or bug fix, or re-factoring): we can check whether it still passes all relevant tests. This is called regression testing.
On delivery of a system: we can ‘test’ whether a system meets a customer’s expectations – this is called acceptance testing.
Why does testing require a different mindset?
Testing requires a different mind-set from construction:
- When constructing (or designing software) , we usually focus on what it will do when things go right
Whereas when testing we focus on finding faults - when things occasionally go wrong
What is unit testing and unit specification?
When we test a unit of code, we aim to increase our confidence that meets its specification. If we don’t have any specification for it its makes it harder, hence we aim to document the intended behaviour of any externally accessible unit
What are the Javadoc Conventions?
The javadoc comment is normally place just before the method it documents and begins with a double asterisk (/**)
- It describes what the method does, what parameters should be passed in, and what result will be returned
- It uses the @param markup to describe each parameter
It uses the @ return markup to describe the return value
What is Documenting Code?
Provides some way of documenting the specification of units inline (in the body of the code rather than in a separate reference manual) and extracting that documentation for use by developers
REFER TO SLIDES FOR EXAMPLES
What is an API?
Stands for Application Programming Interface, it is the specification for all externally accessible classes methods and so on in a module
- It is considered a contract between the developer of the function and the client code using it
○ Think of it as a promise to the user for the function to do something, such as returning a number/value
○ Based on the idea “if you the client code, pass me arguments which met the following criteria I promise to the following”
Where the following thing is returning some sort of value
What is a side effect?
Anything the function does to alter the current of subsequent behaviour of the system or its interaction with external system, other than its returning value
REFER TO SLIDES FOR EXAMPLE
In API what is specification vs implementation?
The API documentation does not normally say how the function is to be implemented, but rather just what its return and effects are.
The functions are a form of abstraction , they allow the function without knowing how it is implemented
What should go into API Documentation?
There are two things:
- The Preconditions: any conditions which should be satisfied by the parameters or the system state when the function is called
The Postconditions: the return value of the function and any changes that function makes to the system state
What happens if the preconditions are not satisfied?
If the preconditions are not satisfied then the behaviour is undefined. This means the user has failed to live up to their part of the bargain and has no guarantees about what the system might do
Once we know the preconditions and postconditions for a function we can write tests for it