7-CodingAndUT.ppt

Coding 1
Coding and Unit Testing

Coding 2
Coding
 Goal is to implement the design in best
possible manner
 Coding affects testing and maintenance
 As testing and maintenance costs are high,
aim of coding activity should be to write code
that reduces them
 Hence, goal should not be to reduce coding
cost, but testing and maint cost, i.e. make
the job of tester and maintainer easier

Coding 3
Coding…
 Code is read a lot more
 Coders themselves read the code many times for
debugging, extending etc
 Maintainers spend a lot of effort reading and
understanding code
 Other developers read code when they add to
existing code
 Hence, code should be written so it is easy to
understand and read, not easy to write!

Coding 4
Coding…
 Having clear goal for coding will help achieve
them
 Weinberg experiment showed that coders
achieve the goal they set
 Diff coders were given the same problem
 But different objectives were given to diff
programmers – minimize effort, min size, min
memory, maximize clarity, max output clarity
 Final programs for diff programmers generally
satisfied the criteria given to them

Coding 5
Weinberg experiment..
Resulting Rank (1=best)
O1 o2 o3 o4 o5
Minimize Effort (o1)
Minimize prog size (o2)
Minimize memory (o3)
Maximize code clarity (o4)
Maximize output clarity (o5)
1 4 4 5 3
2-3 1 2 3 5
5 2 1 4 4
4 3 3 2 2
2-3 5 5 1 1

Coding 6
Programming Principles
 The main goal of the programmer is write
simple and easy to read programs with few
bugs in it
 Of course, the programmer has to develop it
quickly to keep productivity high
 There are various programming principles
that can help write code that is easier to
understand (and test…)

Coding 7
Structured Programming
 Structured programming started in the
70s, primarily against indiscriminate use
of control constructs like gotos
 Goal was to simplify program structure
so it is easier to argue about programs
 Is now well established and followed

Coding 8
Structured Programming…
 A program has a static structure which is the
ordering of stmts in the code – and this is a
linear ordering
 A program also has dynamic structure –order
in which stmts are executed
 Both dynamic and static structures are
ordering of statements
 Correctness of a program must talk about the
dynamic structure

Coding 9
 To show a program as correct, we must show that its
dynamic behavior is as expected
 But we must argue about this from the code of the
program, i.e. the static structure
 I.e program behavior arguments are made on the
static code
 This will become easier if the dynamic and static
structures are similar
 Closer correspondence will make it easier to
understand dynamic behavior from static structure
 This is the idea behind structured programming

Coding 10
 Goal of structured programming is to
write programs whose dynamic
structure is same as static
 I.e. stmts are executed in the same
order in which they are present in code
 As stmts organized linearly, the
objective is to develop programs whose
control flow is linear

Coding 11
 Meaningful programs cannot be written as
seq of simple stmts
 To achieve the objectives, structured
constructs are to be used
 These are single-entry-single-exit constructs
 With these, execution of the stmts can be in
the order they appear in code
 The dynamic and static order becomes same

Coding 12
Structured Programming
 Main goal was to ease formal verification of
programs
 For verification, the basic theorem to be
shown for a program S is of the form
P {S} Q
 P – precondition that holds before S executes
 Q – postcondition that holds after S has
executed and terminated

Coding 13
Structured Prog – composing
proofs
 If a program is a sequence of the type S1; S2
then it is easier to prove from proofs of S1
and S2
 Suppose we have shown P1 {S1} Q1 and R2
{S2} Q2
 Then, if we can show Q1 => R2, then we can
conclude P1 {S1; S2} Q2
 So Structured Prog allows composing proofs
of larger programs from proofs of its parts

Coding 14
 Each structured construct should also have a
clear behavior
 Then we can compose behavior of stmts to
understand behavior of programs
 Hence, arbitrary single-entry-single-exit
constructs will not help
 It can be shown that a few constructs like
while, if, and sequencing suffice for writing
any type of program

Coding 15
 SP was promulgated to help formal
verification of programs
 Without linear flow, composition is hard and
verification difficult
 But, SP also helps simplify the control flow of
programs, making them easier to understand
and argue about
 SP is an accepted and standard practice today
– modern languages support it well

Coding 16
Information Hiding
 Software solutions always contain data
structures that hold information
 Programs work on these DS to perform the
functions they want
 In general only some operations are
performed on the information, i.e. the data is
manipulated in a few ways only
 E.g. on a bank’s ledger, only debit, credit,
check cur balance etc are done

Coding 17
Information Hiding…
 Information hiding – the information should
be hidden; only operations on it should be
exposed
 I.e. data structures are hidden behind the
access functions, which can be used by
programs
 Info hiding reduces coupling
 This practice is a key foundation of OO and
components, and is also widely used today

Coding 18
Some Programming Practices
 Control constructs: Use only a few
structured constructs (rather than using
a large no of constructs)
 Goto: Use them sparingly, and only
when the alternatives are worse
 Info hiding: Use info hiding
 Use-defined types: use these to make
the programs easier to read

Coding 19
Some Programming Practices..
 Nesting: Avoid heavy nesting of if-then-
else; if disjoint nesting can be avoided
 Module size: Should not be too large –
generally means low cohesion
 Module interface: make it simple
 Robustness: Handle exceptional
situations
 Side effects: Avoid them, document

Coding 20
Some Programming Practices..
 Empty catch block: always have some default
action rather than empty
 Empty if, while: bad practice
 Read return: should be checked for
robustness
 Return from finally: should not return from
finally
 Correlated parameters: Should check for
compatibility

Coding 21
Coding Standards
 Programmers spend more time reading code than
writing code
 They read their own code as well as other
programmers code
 Readability is enhanced if some coding conventions
are followed by all
 Coding standards provide these guidelines for
programmers
 Generally are regarding naming, file organization,
statements/declarations, …
 Some Java conventions discussed here

Coding 22
Coding Standards…
 Naming conventions
 Package name should be in lower case
(mypackage, edu.iitk.maths)
 Type names should be nouns and start with
uppercase (Day, DateOfBirth,…)
 Var names should be nouns in lowercase; vars
with large scope should have long names; loop
iterators should be i, j, k…
 Const names should be all caps
 Method names should be verbs starting with lower
case (eg getValue())
 Prefix is should be used for boolean methods

Coding 23
Coding Standards…
 Files
 Source files should have .java extension
 Each file should contain one outer class
and the name should be same as file
 Line length should be less than 80; if
longer continue on another line…

Coding 24
Coding Standards…
 Statements
 Vars should be initialized where declared in the
smallest possible scope
 Declare related vars together; unrelated vars
should be declared separately
 Class vars should never be declared public
 Loop vars should be initialized just before the loop
 Avoid using break and continue in loops
 Avoid executable stmts in conditionals
 Avoid using the do… while construct

Coding 25
Coding Standards…
 Commenting and layout
 Single line comments for a block should be
aligned with the code block
 There should be comments for all major
vars explaining what they represent
 A comment block should start with a line
with just /* and end with a line with */
 Trailing comments after stmts should be
short and on the same line

Coding 26
Incrementally Developing
Code
 Coding starts when specs for modules from
design is available
 Usually modules are assigned to
programmers for coding
 In top-down development, top level modules
are developed first; in bottom-up lower levels
modules
 For coding, developers use different
processes; we discuss some here

Coding 27
An Incremental Coding Process
 Basic process: Write code for the
module, unit test it, fix the bugs
 It is better to do this incrementally –
write code for part of functionality, then
test it and fix it, then proceed
 I.e. code is built code for a module
incrementally

Coding 29
Test Driven Development
 This coding process changes the order
of activities in coding
 In TDD, programmer first writes the
test scripts and then writes the code to
pass the test cases in the script
 This is done incrementally
 Is a relatively new approach, and is a
part of the extreme programming (XP)

Coding 30
TDD…
 In TDD, you write just enough code to pass
the test
 I.e. code is always in sync with the tests and
gets tested by the test cases
 Not true in code first approach, as test cases may
only test part of functionality
 Responsibility to ensure that all functionality
is there is on test case design, not coding
 Help ensure that all code is testable

Coding 31
TDD…
 Focus shifts to how code will be used as test
cases are written first
 Helps validate user interfaces specified in the
design
 Focuses on usage of code
 Functionality prioritization happens naturally
 Has possibility that special cases for which
test cases are not possible get left out
 Code improvement through refactoring will be
needed to avoid getting a messy code

Coding 33
Pair Programming
 Also a coding process that has been proposed
as key practice in XP
 Code is written by pair of programmers rather
than individuals
 The pair together design algorithms, data
structures, strategies, etc.
 One person types the code, the other actively
reviews what is being typed
 Errors are pointed out and together solutions are
formulated
 Roles are reversed periodically

Coding 34
Pair Programming…
 PP has continuous code review, and reviews
are known to be effective
 Better designs of algos/DS/logic/…
 Special conditions are likely to be dealt with
better and not forgotten
 It may, however, result in loss of productivity
 Ownership and accountability issues are also
there
 Effectiveness is not yet fully known

Coding 35
Managing Evolving Code
 During coding process, code written by
a programmer evolves
 Code by different programmers have to
be put together to form the system
 Besides normal code changes,
requirement changes also cause chg.
 Evolving code has to be managed

Coding 36
Source Code Control and Built
 Source code control is an essential step
programmers have to do
 Generally tools like CVS, VSS are used
 A tool consists of repository, which is a
controlled directory structure
 The repository is the official source for all the
code files
 System build is done from the files in the
repository only
 Tool typically provides many commands to
programmers

Coding 37
Source code control…
 Checkout a file: by this a programmer gets a
local copy that can be modified
 Check in a file: changed files are uploaded in
the repository and change is then available to
all
 Tools maintain complete change history and
all older versions can be recovered
 Source code control is an essential tool for
developing large projects and for coordination

Coding 38
Refactoring
 As code evolves, the design becomes
more complex
 Refactoring is a technique to improve
existing code by improving its design
(i.e. the internal structure)
 In TDD, refactoring is a key step
 Refactoring is done generally to reuce
coupling or increase cohesion

Coding 39
Refactoring…
 Involves changing code to improve
some design property
 No new functionality is added
 To mitigate risks associated with
refactoring two golden rules
 Refactor in small steps
 Have test scripts available to test that the
functionality is preserved

Coding 40
Refactoring…
 With refactoring code is continually
improving; refactoring cost is paid by
reduced maint effort later
 There are various refactoring patterns
that have been proposed
 A catalog of refactorings and how to do
them is available online

Coding 41
Refactoring…
 “Bad smells” that suggest that refactoring
may be desired
 Duplicate code
 Long method
 Long class
 Long parameter list
 Swith statement
 Speculative generality
 Too much communication between objects
 …

Coding 43
UT and Verification
 Code has to be verified before it can be used
by others
 Here we discuss only verification of code
written by a programmer (system verification
is discussed in testing)
 There are many different techniques – two
most commonly used are unit testing and
inspection
 We will discuss these here

Coding 44
Unit Testing
 Is testing, except the focus is the module a
programmer has written
 Most often UT is done by the programmer
himself
 UT will require test cases for the module –
will discuss in testing
 UT also requires drivers to be written to
actually execute the module with test cases
 Besides the driver and test cases, tester
needs to know the correct outcome as well

Coding 45
Unit Testing…
 If incremental coding is being done, then
complete UT needs to be automated
 Otherwise, repeatedly doing UT will not be
possible
 There are tools available to help
 They provide the drivers
 Test cases are programmed, with outcomes being
checked in them
 I.e. UT is a script that returns pass/fail

Coding 46
Unit Testing…
 Testing a module f() has following steps
 Set the system state as needed
 Set value of parameters suitably
 Invoke the function f() with parms
 Compare result of f() with expected results
 Declare whether the test case succeeded
or failed
 Test frameworks automate all this

Coding 47
Unit testing of Classes
 Is same as before, except the system state is
generally the state of the object
 Many frameworks exist for OO – Junit is the
most popular; others for other languages also
exist
 Each testcase is a method, in which the
desired sequence of methods is executed;
assertions used to check the outcome
 The script will declare if all tests succeeded,
and if not which ones have failed

Coding 48
Unit Testing…
 There are frameworks like Junit that can be
used for testing Java classes
 Each test case is a method which ends with
some assertions
 If assertions hold, the test case pass,
otherwise it fails
 Complete execution and evaluation of the test
cases is automated
 For enhancing the test script, additional test
cases can be added easily

Coding 49
Code Inspections
 Code inspection is another technique that is
often used effectively at the unit level
 Main goal of inspection process is to detect
defects in work products
 First proposed by Fagan in 70s
 Earlier used for code, now used for all types
of work products
 Is recognized as an industry best practice

Coding 50
Code review…
 Conducted by group of programmers for
programmers (i.e. review done by peers)
 Is a structured process with defined roles
for the participants
 The focus is on identifying problems, not
resolving them
 Review data is recorded and used for
monitoring the effectiveness

Coding 51
A Review Process
Work Product for
review
Planning Preparation & Overview
Schedule,
Review Team,
Invitation
Group Review Meeting
Defects Log,
Recommendation
Rew ork & Follow Up
Reviewed Work
Product, Summary
Report

Coding 52
Planning
 Select the group review team – three to
five people group is best
 Identify the moderator – has the main
responsibility for the inspection
 Prepare package for distribution – work
product for review plus supporting docs
 Package should be complete for review

Coding 53
Overview and Self-Review
 A brief meeting – deliver package, explain
purpose of the review, intro,…
 All team members then individually review
the work product
 Lists the issues/problems they find in the self-
preparation log
 Checklists, guidelines are used
 Ideally, should be done in one sitting and
issues recorded in a log

Coding 54
Self-Review Log
Project name:
Work product name and ID:
Reviewer Name
Effort spent (hours)
Defect list
No Location Description Criticality

Coding 55
Group Review Meeting
 Purpose – define the final defect list
 Entry criteria – each member has done
a proper self-review (logs are reviewed)
 Group review meeting
 A reviewer goes over the product line by
line
 At any line, all issues are raised
 Discussion follows to identify if a defect
 Decision recorded (by the scribe)

Coding 56
Group Review Meeting…
 At the end of the meeting
 Scribe presents the list of defects/issues
 If few defects, the work product is
accepted; else it might be asked for
another review
 Group does not propose solutions – though
some suggestions may be recorded
 A summary of the inspections is prepared –
useful for evaluating effectiveness

Coding 57
Group Review Meeting…
 Moderator is in-charge of the meeting
and plays a central role
 Ensures that focus is on defect detection
and solutions are not discussed/proposed
 Work product is reviewed, not the author
of the work product
 Amicable/orderly execution of the meeting
 Uses summary report to analyze the overall
effectiveness of the review

Coding 58
Summary Report Example
Project
Work Product Type
Size of work product
Review team
Effort (person hours)
Preparation
Group meeting
Total
XXXX
Class AuctionItem
250 LOC of Java
P1, P2, P3
3 person-hrs (total)
4.5 person-hrs
7.5

Coding 59
Summary Report…
Defects
No of major defects
No of minor defects
Total
Review status
Reco for next phase
Comments
3
8
11
Accepted
Nil
Code can be improved

Coding 60
Summary Report…
 Defect density found – 3/0.25 = 12
major defects/KLOC
 Seems OK from experience
 Similarly for total and minor density
 Preparation rate – about 250/1 = 250
LOC / hr : Seems OK
 Group review rate: 250/1.5 = 180
LOC/hr; seems OK

Coding 61
Rework and Follow Up
 Defects in the defects list are fixed later
by the author
 Once fixed, author gets it OKed by the
moderator, or goes for another review
 Once all defects/issues are satisfactorily
addressed, review is completed and
collected data is submitted

Coding 63
Metrics for Size
 LOC or KLOC
 non-commented, non blank lines is a
standard definition
 Generally only new or modified lines are
counted
 Used heavily, though has shortcomings

Coding 64
Metrics for Size…
 Halstead’s Volume
 n1: no of distinct operators
 n2: no of distinct operands
 N1: total occurrences of operators
 N2: Total occurrences of operands
 Vocabulary, n = n1 + n2
 Length, N = N1 + N2
 Volume, V = N log2(n)

Coding 65
Metrics for Complexity
 Cyclomatic Complexity is perhaps the most
widely used measure
 Represents the program by its control flow
graph with e edges, n nodes, and p parts
 Cyclomatic complexity is defined as V(G) = e-
n+p
 This is same as the number of linearly
independent cycles in the graph
 And is same as the number of decisions
(conditionals) in the program plus one

Coding 66
Cyclomatic complexity example…
1. {
2. i=1;
3. while (i<=n) {
4. J=1;
5. while(j <= i) {
6. If (A[i]<A[j])
7. Swap(A[i], A[j]);
8. J=j+1;}
9. i = i+1;}
10. }

Coding 68
Example…
 V(G) = 10-7+1 = 4
 Independent circuits
1. b c e b
2. b c d e b
3. a b f a
4. a g a
 No of decisions is 3 (while, while, if);
complexity is 3+1 = 4

Coding 69
Complexity metrics…
 Halsteads
 N2/n2 is avg times an operand is used
 If vars are changed frequently, this is
larger
 Ease of reading or writing is defined as
D = (n1*N2)/(2*n2)
 There are others, e.g. live variables,
knot count..

Coding 70
Complexity metrics…
 The basic use of these is to reduce the
complexity of modules
 One suggestion is that cyclomatic
complexity should be less than 10
 Another use is to identify high
complexity modules and then see if
their logic can be simplified

Coding 71
Summary
 Goal of coding is to convert a design into
easy to read code with few bugs
 Good programming practices like structured
programming, information hiding, etc can
help
 There are many methods to verify the code of
a module – unit testing and inspections are
most commonly used
 Size and complexity measures are defined
and often used; common ones are LOC and
cyclomatic complexity

7-CodingAndUT.ppt

Recommended

More Related Content

Similar to 7-CodingAndUT.ppt (20)

More from DuraisamySubramaniam1 (7)

Recently uploaded (20)

7-CodingAndUT.ppt