Good Programming Practice - Students

You might also like

Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 20

Good programming practice

Chris Rowlands
Software and Testing

Learning outcomes
• Gain an appreciation for how software is written at scale
• Understand basic errors, trapping and handling
• Know why we should use version control, and how to use it
• Understand the Software Development Lifecycle
• Know what unit-testing is, and how to do basic unit-testing
Software and Testing

Outline
• Errors and error handling
– Try / Except / Else
• Version Control
– Git
• Systems Development Life Cycle (SDLC)
• Unit testing
– Assert
Software and Testing

Error handling
• Warnings don’t mean anything bad has happened, but you might want to be
aware of something
• Syntax errors: the code doesn’t make sense
• Exceptions: Something went wrong
– Passed to the user by default
– Can be automatically handled
• Built-in exceptions: https://docs.python.org/3/library/exceptions.html
– TypeError: The code tried to pass a variable with the wrong data type to
a function or variable
– NameError: the code refers to a name, but that name can’t be found
– ZeroDivisionError: The code tried to divide by zero
• Can add your own
Software and Testing

Try / Except / Else blocks


• Sometimes known as Try / Catch blocks
• try: Execute the following code, but instead of passing exceptions to the
user, trap them and handle them automatically.
• except anException: If anException occurs, don’t notify the user – run
this code instead.
• else: If no exceptions, run this code.
Software and Testing

Version Control
Approach Why are you wrong? Examples
No version What do you do if your code has a bug? Too many
control developers
Local backups Backups can be overwritten easily, and merging Windows
bugfixes from one version to another is hard Explorer
Local version How can other people easily make changes to RCS
control your code without breaking everything?
Centralized Not bad, but you usually need to pay for the CVS,
version control server, and you have a single point of failure Subversion
Distributed You aren’t; this is current standard practice for Git,
version control many software development projects Mercurial
Software and Testing

Version control – what does it do?


• Separate development code that might potentially break, from production
code which should always work
• Allow parallel development on multiple features independently, without
breaking other people’s code
• Track development to determine at what point bugs were introduced
– Also so we can blame the person who introduced them
• Document all changes to the codebase by including commit messages
describing what changed and why
Software and Testing

Using Git, GitHub and GitKraken


• Git: Created by Linus Torvalds to provide
version control for the Linux kernel
– Named after himself (allegedly)
• GitHub: a free Git repository for hosting your
projects
– Imperial pays for free private repositories
for research
– Owned by Microsoft. Alternatives include
BitBucket, SourceForge, GitLab
• GitKraken: A graphical user interface for Git
– Cross-platform – works on Raspberry Pi
– Owned by Axosoft. Alternatives include
SourceTree and Tower
Software and Testing

Git: Some terminology


• Repository: The complete commit history for all branches, all tags and all
files in the project.
• Branch: An independent line of development.
• Checkout: To select which branch you’re going to work on.
• Commit: A package of changes made to a branch.
• Tag: A marker in the commit chain that highlights something important
• Merge: To combine the commits from two branches into one
– May require you to address conflicts
• Push: update a remote repository with the changes in your local repository
• Pull: update your local repository with the changes from a remote one.
Software and Testing

Using GitKraken / Git


• Create a new repository
• Make a branch and edit something
• Merge the branch back into the
trunk (master)
• Start another branch, and change
something else
• Merge the branch into the trunk, and
resolve conflicts
Software and Testing

The Systems Development Life Cycle


• Building complex systems using
structured, well-understood paradigms
– Waterfall model
– Spiral
– Extreme Programming (XP)
– Agile Development
• Several stages are common:
– Eliciting requirements
– Designing the system
– Implementing the design
– Verifying that requirements are
met
Software and Testing

The V-Model
Software and Testing

Software Requirements Specification


• Software-specific version of the Concept of Operations
• Define the purpose of the system (“product requirements”)
• Describe an overall description of the final product
– System interfaces, user interface, design constraints etc.
• Highlight any specific requirements
– Performance, security, hardware limitations, uptime etc.
• Why use a Software Requirements Specification?
– Allow the project to be reviewed / assessed
– Agreeing the scope of the project
– Giving overall guidance to the designers / architects / engineers
– Describing a framework that can be used for testing
Software and Testing

Software Requirements Specification


• SWEBOK V3 (ISO/IEC
1
4 Purpose
Product Functions
TR 19759:2005)
2
5 Scope
User Characteristics
• International Standard 3
6 Product
Limitations
Perspective
ISO/IEC/IEEE 73.1
Assumptions
System Interfaces
and Dependencies
29148:2018 83.2
Apportioning
User Interfaces
of Requirements
93.3
Specific
Hardware
Requirements
Interfaces
103.4
External
SoftwareInterfaces
Interfaces
113.5
Functions
Communications Interfaces
123.6
Usability
MemoryRequirements
constraints
133.7
Performance
Operations Requirements
143.8
Verification
Site Requirements
15 Supporting Information
Software and Testing

Focusing on one bit: Unit Testing


• Automated testing of code every time is it written / rewritten
– Units are the smallest piece of testable code
• Dos:
– Use a proper framework
– Write tests every time you add a new feature (ideally before)
– Run them whenever you change a piece of code (incorporate them into
the build step if possible)
• Don’t:
– Make your test dependent on an external object. Write a mock interface
if you need to.
– Test the same thing multiple times with random inputs; that’s fuzzing.
– Test more than one unit simultaneously.
Software and Testing

Other tests (non-exhaustive list)


• Integration testing (performed by developers)
– Do all the individual modules function together to produce a desired
result?
• System testing (performed by developers)
– Does the system as a whole fit the Software Requirements Specification?
• Acceptance testing (performed by users)
– Does the system fulfil the goal(s) of the project?
Software and Testing

Simple unit testing in Python with assert


• Inferior alternative to unittest, not a bad option for beginners though
• assert expression will throw AssertionError if expression isn’t
True
– Use assert to check if a function produces correct output
– Won’t throw AssertionError if another error occurs first
Software and Testing

Unit testing example


Software and Testing

Summary
• Discussed errors, try / except / else
• Introduced version control, the reasons for using it, and the basics of git
• Presented the SDLC, V-model, software requirements specification
• Discussed unit testing and how it helps prevent bugs / regressions
Software and Testing

Recommended reading
• SWEBOK V3 (IEEE)
• Test Driven Development By Example (Kent Beck)
• Clean Architecture: A Craftsman’s Guide to Software Structure and Design
(Robert C Martin)

You might also like