Three Basic Techniques of S.E.

1
Three Basic Techniques of S.E.

• Automated build
• Configuration management
• Automated test

2
Automated build

• Building a program you can run
• Build requires
• Compiling files
• Running preprocessors
• Linking, building JARs, etc
• Must build everything with one command
• Make - C, Unix
• Ant - Java

3
Build scripts

• A single system usually has several build scripts
• make
• make print
• make install
• make clean

4
Configuration management

• A.k.a. version management, version control
• Keeping track of versions of software

5
Why CM?

• Multiple developers
• Multiple phases (alpha, beta, released)
• Multiple released versions of software
• Multiple platforms for software

6
Simple CM

• A directory for each version
• Make new version by copying old
• Two developers never edit same file at same time

7
More complex CM

• All versions stored in a database
• Each file is stored in database separately
• fetch version 3.4 of all files and put them into
  johnson/project3.4
• Edit files, compile, test, etc.
• store johnson/project3.4 as next version

8
Problems

• What if two developers want to change the same
  file?
• 1) Dont let them. You must lock a file
  before you can edit it. Only one person can lock
  a file.
• 2) Let them. You must resolve differences when
  you check the files back into the database.

9
Locking

• Checkout for reading - readonly file.
• Checkout for writing - writable, but must lock
  file.
• Checkin writable file - create new version,
  unlock file.

10
Problem

• How can you tell whether a set of files are
  compatible?
• 1) Label them. Each file has something like
  version that is put in a comment.
• 2) Group them. The CM system keeps track of all
  related files, and checks them in and out as a
  group.

11
Building software

• make knows all the files it takes to build a
  program
• Why not have CM system know all the files?
• Can check them all out at once
• Can check them in

12
Building software

• Good CM system should be able to retrieve any
  version.
• 1) Store binaries of old versions.
• 2) Know how to rebuild binaries of old versions.
• Must keep old versions of libraries.
• Must keep old versions of compiler, etc.

13
How to use a CM system

• To fix bug
• Check-out most recent version
• Change, compile, test, etc.
• Check-in next version.
• If someone checked-in before you, get the
  changes, manually merge them, compile, test, etc.
  Try again.

14
How to use a CM system

• Never check out code for a long time.
• When you check-in, youll find lots of conflicts.
  It will take a long time to make your code ready
  to check-in.
• So, make lots of small changes rather than a few
  big ones.

15
CM tools

• Unix - CVS, subversion
• Windows - SourceSafe
• See http//www.enteract.com/bradapp/links/scm-lin
  ks.html

16
Automated testing

• Manual testing - run program, give input, see if
  it gives the right output
• Automated testing - run tests, which run program
  and tell you if it gives the right output
• Automated tests
• More work up-front
• Easier to run

17
Automated tests

• Junit - test Java program by writing tests in
  Java
• Each test is a method in a subclass of TestCase
• TestRunner - run single test or a suite of tests
• You are notified if any tests fail

18
Automated tests

• Tend to depend on programming language
• Unit testing frameworks
• http//en.wikipedia.org/wiki/XUnit

19
Automated tests

• Unit tests - test each unit of the program
• Low level
• Always language specific
• Functional tests - test overall functions
• High level
• Can be language independent - test I/O

20
Typical test

• Set up parameters
• Call function
• Check to see if results are correct

21
Building and CM

• Store build script in your CM
• Add a new file to CM, add it to build script

22
Building and testing

• Run tests when you build
• You can use build script to run tests make test

23
CM and tests

• Include tests in code base
• Tests only run with particular version of code
• Make sure all tests run before you check in code
• Dont break other peoples code
• Protect your code from other people by writing
  tests