Coding and Testing in software engineering

 

●      Coding is undertaken once the design phase is complete and the design documents

have been successfully reviewed.

●      In the coding phase, every module specified in the design document is

coded and unit tested. During unit testing, each module is tested in isolation

from other modules.

●      After all the modules of a system have been coded and unit tested, the integration

and system testing phase is undertaken.

●      Integration and testing of modules is carried out according to an integration plan.

●      The integration plan, according to which different modules are integrated together, usually envisages integration of modules through a number of steps.

10.1 CODING

The input to the coding phase is the design document produced at the end of

the design phase.

The objective of the coding phase is to transform the design of a system into code in

a high-level language, and then to unit test this code. 

The main advantages of adhering to a standard style of coding are the following: 

A coding standard gives a uniform appearance to the codes written by

different engineers.

It facilitates code understanding and code reuse.

It promotes good programming practices.

10.1.1 Coding Standards and Guidelines

Good software development organisations usually develop their own

coding standards and guidelines depending on what suits their

organisation best and based on the specific types of software they

Develop.

Representative coding standards

Rules for limiting the use of globals:

Standard headers for different modules:

Naming conventions for global variables, local variables, and

constant identifiers:

Conventions regarding error return values and exception handling

Mechanisms:

Representative coding guidelines:

Do not use a coding style that is too clever or too difficult to

Understand:

Avoid obscure side effects: The side effects of a function call include

modifications to the parameters passed by reference, modification of global

variables, and I/O operations.

Do not use an identifier for multiple purposes: Programmers often use

the same identifier to denote several temporary entities.

Code should be well-documented:

Length of any function should not exceed 10 source lines:

Do not use GO TO statements:

 

 

10.2 CODE REVIEW

 

Code review for a module is undertaken after the module successfully

Compiles.

 

The reason behind why code review is a much more cost-effective strategy

to eliminate errors from code compared to testing is that reviews directly

detect errors.

 

the following two types of reviews are carried out on the code of

a module:

Code inspection.

Code walkthrough.

The procedures for conduction and the final objectives of these two review

techniques are very different.

 

10.2.1 Code Walkthrough

Code walkthrough is an informal code analysis technique. In this technique,

a module is taken up for review after the module has been coded,

successfully compiled, and all syntax errors have been eliminated.

 

The main objective of code walkthrough is to discover the algorithmic and logical

errors in the code.

 

10.2.2 Code Inspection

During code inspection, the code is examined for the presence of some

common programming errors.

The principal aim of code inspection is to check for the presence of some common

types of errors that usually creep into code due to programmer mistakes and

oversights and to check whether coding standards have been adhered to.

Following is a list of some classical programming errors which can be

checked during code inspection:

Use of uninitialised variables.

Jumps into loops.

Non-terminating loops.

Incompatible assignments.

Array indices out of bounds.

Improper storage allocation and deallocation.

Mismatch between actual and formal parameter in procedure calls.

Use of incorrect logical operators or incorrect precedence among

operators.

Improper modification of loop variables.

Comparison of equality of floating point values.

Dangling reference caused when the referenced memory has not been

Allocated.

10.2.3 Clean Room Testing

Clean room testing was pioneered at IBM. This type of testing relies heavily on walkthroughs, inspection, and formal verification.