1 / 23

Three Basic Techniques of S.E.

Three Basic Techniques of S.E. Automated build Configuration management Automated test. 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.

herrod-hodges
Download Presentation

Three Basic Techniques of S.E.

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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) Don’t 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, you’ll 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-links.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 • Don’t break other people’s code • Protect your code from other people by writing tests

More Related