Unit 5

Coding and
Unit Testing
 5.1 Programming Principles and Guidelines
• Writing a quality code with least number of bugs is a challenging task. Writing such code is a
skilful activity and by practicing one can gain such skill. However, there are some guidelines
used by the programmer while writing the code.
• There are some programming practices as follow which helps in avoiding the common
errors:
– Control structure: The standard control construct like single entry/exit must be used.
– Use of goto statements: Avoid use of goto statements as it makes program unstructured and imposes
overhead on compilation process.
– Information hiding: It should be supported as far as possible.
– Nesting: It means defining one structure inside another. Avoid deep nesting as then it becomes hard to
understand the code.
– User defined datatypes: In modern programming languages, it is allowed as enumerated types. Use of
this kind of datatypes enhances readability of the code.
Continued…
– Module size: There is no standard rule for size of module. But large size of module will not be
functionally cohesive.
– Module interface: Complex module interface must be carefully examined. A simple rule of
thumb is that the module interface with more than five parameters must be broken into
multiple modules with simple interface.
– Side effects: Avoid obscure side effects. If some part of the code is changed randomly then it
will cause some side effect. E.g. if number of parameters passed to the function is changed then
it will be difficult to understand the purpose of the function.
– Robustness: The program is said to robust if it does something even though some unexceptional
condition occurs. In such situations the programs do not crash but it exists gracefully.
– Switch case with defaults: The choice being passed to the switch case statement may have
some unpredictable value, and then the default case will help to execute the switch case
statement without any problem.
 5.2 Coding Standards
• Any good software development approach suggests to adhere to some well-defined
standards or rules for coding. These rules are called coding standards.
1. Naming Conventions
• Following are some commonly used naming conventions in the coding:
– Package name and variable names should be in lower case.
– Variable names must not begin with numbers.
– The type name should be noun and it should start with capital letter.
– Constants must be in upper case.
– Method name must be given in lower case.
– The variables with large scope and small scope must have long name and short name respectively. E.g.
count_total, sum,i,j etc.
– The prefix must be used for Boolean type of variables. E.g. isEmpty or isFull etc.
 Continued…
2. Files
• Reader must get an idea about the purpose of the file by its name. In some programming language like Java
– The file extension must be java.
– The name of the file and the class defined in the file must have the same name.
– Line length in the file must be limited to 80 characters.
3. Commenting/Layout
• Comments are non executable part of the code. But it is very important because it enhances the
readability of the code. The purpose of the code is to explain the logic of the program.
– Single line must be given by ‘//’.
– For the names of the variable comments must be given.
– A black of comment must be enclosed within ‘/* and */’.
 Continued…
4. Statements
• There are some guidelines about the declaration and executable statements.
– Declare some related variables on same line and unrelated variables on another line.
– Class variable should never be declared public.
– Make use of only loop control within the for loop.
– Avoid make use of break and continue statements in the loop.
– Avoid complex conditional expressions. Make use of temporary variables instead.
– Avoid the use of do…while statement.

• Advantages of Coding Standards

– Coding standard brings uniform appearance in system implementation.
– The code becomes readable and hence can be understood easily.
– The coding standard helps in adopting good programming practices.
5.3 Incremental Development of Code
Specification of the module

Write a code to implement functionality

Fix Error

Write a test script for testing the functionality

Yes Error occurs in the

Execute the test script
functionality?

No

Covered all the

functions from
No specification?

Yes
 Continued…
• The coding starts after the completion of the design activity. Some specification for the
functionalities must be available. For developing the code incremental approach is adopted.
Figure shows incremental development approach.
• In this approach for each functionality the code is written and it is tested.
• If the bug is found in this functionality then it is corrected and then the code for next
functionality is written.
• After covering all the functionalities mentioned in the specification, the process is
terminated.
• The advantage of incremental development of code is that, each and every functionality is
written and then immediately tested.
 5.4 Management of Code
• Different people develop different source code. Each programmer creates different source
files which are combined at the end to create an executable file. The developers develop the
code and make changes as the project evolves. Hence there is a need to manage such code.

• The UNIX makes use of an utility called CVS using which the source code can be controlled.
Windows also provide such type of controlling utility by means of a tool called visual safe.

• The code management system contains a central repository in which there exists a control
directory structure which keeps the full revision history of all the files. For efficiency, a file
history is generally kept as deltas or increments from the base file. Thus using the older
version any file can be recreated. The repository is also the official source for all the files.
 Continued…
• Various commands that are performed by the programmer on the repository are –
– Get a local copy: The local copy of the repository is obtained by the programmer and programmer often
works on it. Making local copy is called checkout.
– Make changes in the file: The changes are made in the local copy of the file. These changes are then
committed back in the repository. This operation is referred check in.
– Update local copy: Changes made in the local copy are not reflected in the local copy of the repository.
Hence using the update command these changes are updated.
– Get report: A detailed report on the evolution made can be obtained. E.g. the report containing the old
data and corresponding changes made, reasons for the changes, corresponding files in which these
changes must be reflected and so on.
• After making these changes, these changes must be available to all the team members of
the project.
• If two persons try to access the same file at a time, then it creates the conflicts. These
conflicts must be solved manually.
 5.5 Unit Testing
• In unit testing the individual components are tested independently to ensure their quality.
• The focus is to uncover the errors in design and implementation.
• The various tests that are conducted during the unit test are described as below:
– Module interfaces are tested for proper information flow in and out of the program.
– Local data are examined to ensure that integrity is maintained.
– Boundary conditions are tested to ensure that the module operates properly at boundaries established to limit or
restrict processing.
– All the basis (independent) paths are tested for ensuring that all statements in the module have been executed
only once.
– All error handling paths should be tested. Interface, Error Handling Paths
Local data structures
Boundary Conditions

Fig.
Module Test
Unit Testing
Cases
Continued…
– Drivers and stub software need to be developed to test incomplete software. The driver is a program that accepts
the test data and prints the relevant results. The stub is a subprogram that uses the module interfaces and
performs the minimal data manipulation if required as shown in below figure.
– The unit testing is simplified when a component with high cohesion is designed. In such a design the number of
test cases are less and one can easily predict or uncover errors.

Interface
Local Data Structures
Boundary Conditions
Independent Paths
Driver Error Handling Paths

Module
Results Test
Cases
Stub Stub Stub
Fig. Unit Testing Environment
 5.6 Code Inspection
• The goal of code inspection is to detect the defects in the code. The code inspection is applied after
successful compilation of the code. For a code inspection a team of following members is required:
1. Moderator: Manager or the leader of the code inspection team.
2. Designer: The team responsible for the current phase.
3. Implementer: The team responsible for the next phase.
4. Tester: The person who tests the code. This person must be preferably from SQA team.
• The design document and the document containing the code for the review is distributed to the team
members during code inspection.
• The code inspection also looks for the quality issues of the code. For instance efficiency of the code,
compliance with the coding standards are those things that are discussed during the code inspection.
• A checklist must be prepared while reviewing the code. A sample checklist is as given below:
– Are the definitions exhibits the typing capacities of the language?
– Are there any dangling pointers?
– Is there any use of NULL pointer?
– Is there any assignment of pointer to a NULL value when required?
 Continued…
– Are all array index within a bound?
– Are all the index properly initialized?
– Is there any infinite loop?
– Is there correct condition for the looping?
– Is there any condition such as divide by zero?
– Is there any undeclared variables?
– Are all the output variables got assigned with some value?
– Are all labels referred correctly?
– Will the code execute as per the requirements?
– Does the code satisfy all the local coding standards?
– Do the actual and formal parameters of the function match?
• The advantage of code inspection is effective for finding the defects from the code.
• The disadvantage of code inspection is time consuming and costly process as more people are involved.
• Due to these drawbacks, a single person may carry out code inspection and code reviews.
 5.7 Formal Technical Review (FTR)
• Formal technical reviews involve the analysis of an artefact by a group of technically skilled
people following a specified and documented process. This is a quality assurance activity
performed by software engineers.
• The objectives of FTR
– To uncover errors in function, logic or implementation for any representation of software FTR is an
effective way.
– FTR is done to verify that software being reviewed meets its requirements.
– It ensures that software is represented according to relevant standards (E.g. UML, Structured A&D).
– The formal technical reviews help to achieve uniform software development and make projects more
manageable.

• FTRs include walkthroughs, code inspections and other small group software assessments.
• The Formal Technical Review is conducted in following stages:
1. Preparation
– The formal technical review is done by a group of at least 4 to 5 people. One of them is called team
leader and there are 2 to 3 reviewers. Each reviewer spends 1 or 2 hours reviewing the product and
making notes on it. At the same time, the review leader also reviews the product, establishes an
agenda for the review meeting and schedules a meeting time.
2. Meeting
– Meeting is attended by producer, review leader and all reviewers. One reviewer acts as a recorder, who
notes in writing all the important issues raised during the review. Then a brief introduction to the
product from the producer is given. Producer then proceeds to ‘walk-through’ the product. Reviewers
raise issues. When valid problems or errors are discovered, they are noted by the recorder. At the end
of meeting, all participants must decide whether to accept the product or not.
3. Review reporting and recording
– After review meeting, the recorder produces a review summary report, answering the questions.
• What was reviewed? • Who reviewed it? • What were the findings and conclusion?
– A review issues list should also be created and attached to the summary report.
 Continued…
• Formal technical review guidelines are given below:
– Review the product, not the producer.
– Set an agenda for product review and maintain it.
– Limit debate and rebuttal. It simply is waste of time.
– Identify problem areas but don’t attempt to solve every problem.
– Take written notes.
– Limit the number of participants.
– Insist on advance preparation.
– Develop a checklist for each work product.
– Allocate resources and time.
– Conduct meaningful training.
– Review earlier reviews.
• The formal technical reviews are used to catch up 75% design errors.
 5.8 Metrics
• Metrics are the quantitative measures that enable the software engineers to gain the
insight into the efficiency of software process.
• The software measures are collected from the software engineers and software metrics are
analysed by software managers.
• The work product of software metrics is a set of productivity metrics and quality metrics.

5.8.1 Size Measure

• Size oriented measure is derived by considering size of software that has been produced.
• The organization builds a simple record of size measure for the software projects. It is built
on past experiences of organizations.
• It is a direct measure of software
 Table: Size Measure
Project LOC Effort Cost($) Document(Pgs.) Errors Defects People
ABC 10000 20 170 400 100 12 4
PQR 20000 60 300 1000 129 32 6
XYZ 35000 65 522 1290 280 87 7
… … … … … … … …

• A simple set of size measure that can be developed is given below:

– Size = Kilo Lines of Code (KLOC)
– Effort = Person/month
– Productivity = KLOC/person-month
– Quality = Number of faults/KLOC
– Cost = $/KLOC
– Documentation = Pages of documentation/KLOC
• The size measure is based on the lines of code computation. The lines of code is defined as
one line of text in a source file.
 Continued…
• While counting the lines of code the Simplest Standard is:
– Don’t count blank lines.
– Don’t count comments.
– Count everything else.
• The size oriented measure is not universally accepted method.
• Advantages
– Artefact of software development which is easily counted.
– Many existing methods use LOC as a key input.
– A large body of literature and data based on LOC already exists.
• Disadvantages
– This measure is dependent upon the programming language.
– This method is well designed but shorter program may get suffered.
– It does not accommodate non procedural languages.
– In early stage of development it is difficult to estimate LOC.
 5.8.2 Complexity Measure
• If the complexity is measured in terms of lines of code then it may vary from system to
system.

• For more complex programs use of lines of code as a metric is not sufficient.

• Hence the complexity measure can be done by various methods such as cyclomatic
complexity, Halstead measure and Knot count measure.
 5.8.2.1 Cyclomatic Complexity
• Cyclomatic complexity is a software metric that gives the quantitative measure of logical
complexity of the program.
• The cyclomatic complexity defines the number of independent paths in the basis set of the
program that provides the upper bound for the number of tests that must be conducted to
ensure that all the statements have been executed at least once.
• There are three methods to calculate cyclomatic complexities.
• Method 1: The total number of regions in the flow graph is a cyclomatic complexity.
• Method 2: The cyclomatic complexity, V(G) for a graph G can be defined as
V(G) = E – N + 2 Where E and N is number of edges and nodes in the flow graph respectively.
• Method 3: The cyclomatic complexity, V(G) for a graph G can be defined as
V(G) = P + 1 Where P is total number of predicate nodes in the flow graph.
 Example
• Consider the following code fragment with line numbered.
{
Control Flow Graph
1. if (a<b)
2. F1(); 1
else
{
2 3
3. if (a<c)
4. F2();
else 4 5
5. F3();
} 6
7. }
 Continued… Control Flow Graph

• There are three regions denoted by R1, R2 and R3. 1

• Node 1 and 3 are predicate node because which branch to be
R3
followed is decided at these point i.e. P = 2.
2 R1 3
• Total edges (E) = 7 and Total nodes (N) =6.
R2
• To compute cyclomatic complexity follow below steps: 4 5
• Step - 1: Design flow graph for given code fragment.
• Step - 2: Compute regions, predicate edges and total nodes in the flow graph. 6
• Step - 3: Apply formula in order to compute cyclomatic complexity.
– Cyclomatic complexity: Total number of regions = 3
– Cyclomatic complexity: E – N + 2 = 7 – 6 + 2= 3
– Cyclomatic complexity: P + 1 = 2 + 1 = 3
 5.8.2.2 Halstead Measure
• Halstead’s complexity measurement was developed to measure a program module’s complexity directly
from source code, with emphasis on computational complexity.
• The Halstead’s measure are based on four scalar numbers derived directly from a program’s source code:
– n1 is number of distinct operators
– n2 is number of distinct operands
– N1 is total number of operators
– N2 is total number of operands
• Halstead’s uses certain measures such as program length, program vocabulary, volume, difficulty and effort
for the given algorithm.
• By this Halstead’s is trying to show that the program length can be calculated, volume of the algorithm can
be estimated. The table shows how actually these measures can be obtained.
• The Halstead’s measures are applicable to operational systems and to development efforts once the code
has been written.
• Thus using Halstead’s measurement experimental verification can be performed in software science.
• From these numbers, five measures are derived
1. Program length
– The length of a program is total usage of operators and operands in the program. Length = N1 + N2
2. Program vocabulary
– The program vocabulary is the number of unique operators and operands used in the program. n = n1 + n2
3. Program volume
– The program volume can be defined as minimum number of bits needed to encode the program. V = N log2 n
4. Length estimation
– N = n1 log2 n1 + n2 log2 n2
Measure Symbol Formula
Program Length N N = N1 + N2
Program Vocabulary n n = n1 + n2
Volume V V = N * (log2 n)
Difficulty D D = (n1 / 2) * (N2 / 2)
Effort E E=D*V
 Continued…
• Guidelines for calculating operands and operators:
1. All the variables and constants are considered as operands.
2. Local variables with same name, if occurring in different functions are counted as unique operand.
3. Function calls are considered as operators.
4. The looping statements, do…while, while, for are operators. The statements if, if…else are operators.
The switch…case statements are considered as operators.
5. The reserve words, return, default, continue, break, sizeof are all operators.
6. The brackets, commas, semicolons are operators.
7. The unary and binary operators are considered as operators. The & is considered as operator.
8. In arrays, array name and index are considered as operands and [ ] is considered as operator.
9. All hash directives can be ignored.
10. Comments are not considered.
11. In goto statement, goto is considered as operator and label is considered as operand.
 Example Operands Occurrences Operators Occurrences
swap 1 () 1
• void swap (int a[ ], int i)
a 5 {} 1
{ int temp; i 5 void 1
temp = a[i]; temp 3 int 3
a[i] = a[i+1]; 1 2 [] 5

a[i+1] = temp; } , 1
; 4
= 3
• N = N1 + N2 = 16 + 21 = 37 + 2
• n = n1 + n2 = 9 + 5 = 14 n2 = 5 N2 = 16 n1 = 9 N1= 21

• Estimated length = n1 log2 n1 + n2 log2 n2

= 9(log2 9) + 5(log2 5) = 9(2.19) + 5(2.32)
= 11.60 + 19.77 = 31.37
• Volume = V = N * (log2 n)
= 37(log2 14) = 37(2.63) = 97.64
 5.8.2.3 Knot Count
• Knot is a crossing of control flows.
• These crossings occur due to non structural jumps in the program.
• Typically the goto statements cause this kind non structural jumps
• This metric designed for FORTAN language.
• If the knot is more intertwined then that means the program is more complex.
• The code with large knots is generally extremely difficult to read and understand.

For example if (a < 5)

goto L1

x=10
goto L2

L1 x = 15
Knot
L2 continue
 5.8.3 Comparison of Different Metrics
Size Measure Cyclomatic Complexity Halstead’s Measure Knot Count
• This is simple method • This measure is based on • The measurable • It is basically designed for
of obtaining the the control flow of the quantities of the the FORTRAN programs.
metrics. It is based on programming constructs program are operators
lines of code. such as if-then-else, do- and operands.
while, repeat until and so
on.

• Modules of the same • For larger number of • It is based on length • More number of knots
size can have different decisions larger is the and volume of the indicate more complex is
complexities. complexity. program. the program.