mirror of
https://github.com/jackyzha0/quartz.git
synced 2025-12-24 05:14:06 -06:00
auto update
This commit is contained in:
Jet Hughes
parent
5b9d712738
commit
5aaf035160
18
content/notes/07-testing.md
Normal file
18
content/notes/07-testing.md
Normal file
@ -0,0 +1,18 @@
|
||||
---
|
||||
title: "07-testing"
|
||||
tags:
|
||||
- cosc202
|
||||
---
|
||||
|
||||
# 07-testing
|
||||
|
||||
- [[testing]]
|
||||
- [[test-driven-development]]
|
||||
- [[unit-testing]]
|
||||
|
||||
- undnerstand that testing is useful for detecting bugs
|
||||
- contrast different types of testting
|
||||
- descrive the principle of test driven development
|
||||
- explain how unit tests ar developed
|
||||
- indicate how languages integreate unit test support
|
||||
- apppreiciate limitation of software testing
|
||||
9
content/notes/08-debugging.md
Normal file
9
content/notes/08-debugging.md
Normal file
@ -0,0 +1,9 @@
|
||||
---
|
||||
title: "08-debugging"
|
||||
tags:
|
||||
- cosc202
|
||||
---
|
||||
|
||||
# 08-debugging
|
||||
|
||||
[[debugging]]
|
||||
9
content/notes/09-documentation.md
Normal file
9
content/notes/09-documentation.md
Normal file
@ -0,0 +1,9 @@
|
||||
---
|
||||
title: "09-documentation"
|
||||
tags:
|
||||
- cosc202
|
||||
---
|
||||
|
||||
# 09-documentation
|
||||
|
||||
[[documentation]]
|
||||
16
content/notes/10-continuous-integration-1.md
Normal file
16
content/notes/10-continuous-integration-1.md
Normal file
@ -0,0 +1,16 @@
|
||||
---
|
||||
title: "10-continuous-integration-1"
|
||||
tags:
|
||||
---
|
||||
|
||||
# 10-continuous-integration-1
|
||||
|
||||
[[continuous-integration]]
|
||||
|
||||
1. explain the term continuous integration
|
||||
2. describe different purposes for CI
|
||||
3. indicate how CI jobs are usually triggered
|
||||
4. understand implications of CI running asynchronously
|
||||
5. Exlplain how to manage output from CI jobs
|
||||
6. describe role of stages and jobs within gitlab pipelines
|
||||
7. indicate how CI specifications are stored
|
||||
81
content/notes/11-continuous-integration-2.md
Normal file
81
content/notes/11-continuous-integration-2.md
Normal file
@ -0,0 +1,81 @@
|
||||
---
|
||||
title: "11-continuous-integration-2"
|
||||
tags:
|
||||
- cosc202
|
||||
---
|
||||
|
||||
1. apprecitae that gitlab is a xomplex software
|
||||
2. Understand where CI jobs scripts get run
|
||||
3. explain why reposityory servers can host websites
|
||||
4. Understandhow gitblab dternmimines awhen a CI script failed
|
||||
5. Describe a way in which CI scrupts scan handle secrets
|
||||
6. OUtline uses of local git hook scripts
|
||||
|
||||
# 11-continuous-integration-2
|
||||
|
||||
CI runs pipellines defined in .gitlab-ci.yaml asynchronously
|
||||
|
||||
CI usually tets abd buiolds your prokects
|
||||
|
||||
runs on a repo server. Usuially persistent, internet accessible
|
||||
|
||||
## 1 Gitlab overall architecture
|
||||
 : not in exam
|
||||
- many different services used
|
||||
|
||||
## 2 Gitlab runners
|
||||
run CI scripts
|
||||
|
||||
- gitlab.com is a cloud computing service
|
||||
- allows elf hosting which is what CS does
|
||||
- altitude is a gitlab instance at CS
|
||||
- servers to host runners that run CI scripts
|
||||
- servers that host websites, e.g., cspages.otago.nz
|
||||
- Gitlab can invoke runners that you host
|
||||
- e.g., to use a particular GPU, or other hardware you have
|
||||
- GItlab runner itself is a small program written in Go
|
||||
|
||||
### 2.1 Runner architecture
|
||||
|
||||
- runs jobs
|
||||
- on isolated infrastructure
|
||||
- ... to maintain secrity
|
||||
- that is set up on demand
|
||||
- ... handle load variation
|
||||
- suits cloud computing
|
||||
|
||||
RHS shows GitLab.com's CI hosting: uses google cloud
|
||||
|
||||
|
||||
|
||||
 : not in exam
|
||||
|
||||
## 3 How CI chagned website hosting
|
||||
|
||||
- need to share stifacts produced by CI jobs
|
||||
- using the web to share artefacts is ideal
|
||||
- so now most repo servers also host websites
|
||||
- these are static websites: all content is fixed
|
||||
- CI can run static website generators (SSGs)
|
||||
- git repo contains source code of website
|
||||
- CI pipelines transforms souce code into HTML fiels
|
||||
- HTML files then hosted as a website by repo sever
|
||||
|
||||
e.g., https://cosc202.cspages.otago.ac.nz
|
||||
|
||||
## 4 Debugging CI scripts
|
||||
|
||||
- first ensure config files YAML is valid
|
||||
- vuilt in gitlab editor checks YAML as you type
|
||||
- commands runfrom shell that fail return an exit code
|
||||
- most unix shells sotre exit code of previous commands in $
|
||||
- So if variable $? (return code of prevous command) is non-zero, the previous command failed
|
||||
- Git lab considers CI job as failed if any command fails
|
||||
- your shell scripting can choose to hide this exit code
|
||||
- e.g., `if command supposed to fail; then true; else true; fi`
|
||||
- Complex scripting? Beste to put script in a file and run it from CI
|
||||
|
||||
## 5 Secrets used by CI scripts
|
||||
|
||||
|
||||
|
||||
@ -6,4 +6,77 @@ tags:
|
||||
|
||||
# continuous-integration
|
||||
|
||||
## 1 What is it
|
||||
continuous --> is always happening
|
||||
integration --> connecting software components
|
||||
|
||||
- in contrast to ad hoc, occasional integration:
|
||||
- diverging component developmetnamy break integration
|
||||
- repaiing software may be expensive
|
||||
|
||||
- supports 'aglile' software dev
|
||||
- like test driven development, help catch issues early
|
||||
|
||||
- usually automated
|
||||
|
||||
## 2 Purposes
|
||||
- checking code syntax
|
||||
- e.g., have CI compile the code and report errors
|
||||
- (local devs compilaer may be different from remote)
|
||||
- checking semantics of code
|
||||
- building docs
|
||||
- e.g., auto run javadoc
|
||||
- running projects code tests
|
||||
- auto run JUnit, and report fails
|
||||
|
||||
## 3 Starting CI jobs
|
||||
- from version control
|
||||
- e.g., every commit triggered CI jobs to run
|
||||
- starts on a push to server
|
||||
- manually
|
||||
- on a schedule
|
||||
|
||||
## 4 Runs asnychronously
|
||||
- dont require devs to wait for completion
|
||||
- common to run locally as well as on consistent standard environment
|
||||
|
||||
- other timescales
|
||||
- local checks as you commit
|
||||
- checks as you type
|
||||
- checks as you save
|
||||
|
||||
## 5 Output
|
||||
since CI is asynchronous, its feedback is also
|
||||
|
||||
- e.g.,
|
||||
- web badges showing status
|
||||
- can send emails
|
||||
- messaging platform
|
||||
- e.g., slack, discord, teams
|
||||
- webhooks etc
|
||||
|
||||
git project websites usually provide logging interface,. They will watch scripts in virtual terminal and capture output from CI scripts
|
||||
|
||||
## 6 Github piplines
|
||||
|
||||
- a pipeline has multiple _stages_
|
||||
- e.g., test, build, deploy
|
||||
|
||||
- each stages has multiple _jobs_
|
||||
- e.g., JUnit, custom tests, etc
|
||||
|
||||
## 7 Yaml
|
||||
|
||||
- most Ci frameworks use YAML for their configuration
|
||||
- structured text based formats
|
||||
- python-like format or ≈JSON
|
||||
|
||||
## 8 configurationg from git repo
|
||||
|
||||
- CI config often via file in git top-level directory
|
||||
- CI is version managed
|
||||
|
||||
- Gitlab pipeline specs go into .gitlab-ci.yaml:
|
||||
- shows command sequece to run for a jon, within a stage
|
||||
- output from commands is stored for a subsequent viewing
|
||||
- indicates what files 'artifacts' should be kept from jobs
|
||||
|
||||
70
content/notes/debugging.md
Normal file
70
content/notes/debugging.md
Normal file
@ -0,0 +1,70 @@
|
||||
---
|
||||
title: "debugging"
|
||||
tags:
|
||||
- cosc202
|
||||
---
|
||||
|
||||
# debugging
|
||||
|
||||
removing technical faults
|
||||
isolaing and remove technical faults
|
||||
a human process
|
||||
- requires creativity/disipline/knowledge
|
||||
- deepr understanding of code
|
||||
|
||||
debuggers are tools to help debugging
|
||||
|
||||
## 1 common approaches
|
||||
temporarily add output of diagnostic info
|
||||
- "printf" debugging
|
||||
permanently include calls to logging system
|
||||
- route to terminal, log files etc
|
||||
|
||||
## 2 debugging machine code
|
||||
- cpu runs code instruction by instruction
|
||||
- thus debugger can intervene between instructions
|
||||
- most cpus help debugger interrupt and resume programs
|
||||
- cpu reached current code via a sequence on callers
|
||||
- called **stack trace** , aka back frame, stack frame etc
|
||||
- may reach point where it cannot continue
|
||||
- e.g., integer division by zero, program execution must stop
|
||||
- stack trace of stopped program can be analysed
|
||||
|
||||
## 3 Imperative languages
|
||||
These are language that are executed in a step-wise, sequentail manner.
|
||||
|
||||
- debug symbols
|
||||
- e.g., method named, variable named
|
||||
- source code context
|
||||
- line numbers
|
||||
- variable name
|
||||
- function method names
|
||||
|
||||
## 4 doing debugging
|
||||
### 4.1 stepping skipping running
|
||||
- step into --> steps one statement and steps into function calls
|
||||
- step over --> a step that treats function calls as statement
|
||||
- step out --> return to the instruction after the function call you're in
|
||||
- continue --> go back to running code continuously
|
||||
|
||||
### 4.2 controlling debugger execution
|
||||
|
||||
Can run normally --> debugger wil run when program crashes
|
||||
|
||||
Set Breakpoint --> debugger will stop program when/if that line is reached
|
||||
- conditional breakpoints only suspend if a condition is true
|
||||
|
||||
Watch point --> program is suspended when some data changes (e.g., variables)
|
||||
|
||||
## 5 debugging non imperative languages
|
||||
|
||||
e.g, spreadsheet (Dataflow programming)
|
||||
- no breakpoints
|
||||
- must step through _iterations of computations_
|
||||
|
||||
e.g., Equation
|
||||
- break into smaller parts
|
||||
- try 'compile' it in multiple ways
|
||||
|
||||
e.g., Data base query (declarative programming)
|
||||
- -reexpressign the query and comaring can be useful
|
||||
68
content/notes/documentation.md
Normal file
68
content/notes/documentation.md
Normal file
@ -0,0 +1,68 @@
|
||||
---
|
||||
title: "documentation"
|
||||
tags:
|
||||
- cosc202
|
||||
---
|
||||
|
||||
# documentation
|
||||
|
||||
## 1 Who, what where
|
||||
- Audience
|
||||
- users
|
||||
- other devs
|
||||
- your team members
|
||||
- anyone trying to understand you software
|
||||
- your future self
|
||||
- Locations
|
||||
- source code
|
||||
- project repo
|
||||
- emebedding in program
|
||||
- hosted separately
|
||||
- User expectations
|
||||
- evolving towards software that _facilitates experimentation_
|
||||
- No help docs => everything is self-explanatory
|
||||
- high usability
|
||||
- users familar with many abstractions
|
||||
- e.g., touchscreens, menus, links
|
||||
- API's
|
||||
- for devs writing code to interact with your code
|
||||
- typically coupled with docs
|
||||
- entirely technical audience --> tool generated docs are okay
|
||||
- not self explanatory
|
||||
- used by devs unfamiliar with code base
|
||||
- Project Docs
|
||||
- meaningful commit msgs
|
||||
- extra mangement with e.g., github
|
||||
- issue tracking
|
||||
- ensures relevant material is cross linked where possible
|
||||
- can easily refer to source code
|
||||
- Source code docs
|
||||
- header comments
|
||||
- software licencing
|
||||
- support devs
|
||||
- indicate code ownership
|
||||
- in code comments on fields methods etc
|
||||
- keep in sync with code changes
|
||||
- descriptive variable/class/other names
|
||||
|
||||
## 2 Built in language support
|
||||
- basic
|
||||
- syntax for code comments
|
||||
- indicate that the compiler should ingnore
|
||||
- also more advanced like python "doc strings"
|
||||
- Structured comments and docs
|
||||
- machine parseable comments
|
||||
- e.g., javadocs, perl plain old docs
|
||||
- creates a doc website
|
||||
- uses annotations e.g., @author, @returns, @param
|
||||
- Literate programming
|
||||
- donald knuth suggestions (1984)
|
||||
- source code should be primarily natural language documentation
|
||||
- executable code snippetrs are included within the description
|
||||
- tools are used to:
|
||||
- tangle the code snippets
|
||||
- weave out the documentation
|
||||
- Modern implementations
|
||||
- jupyter notebooks
|
||||
- swift playgrounds
|
||||
- r markdown
|
||||
17
content/notes/test-driven-development.md
Normal file
17
content/notes/test-driven-development.md
Normal file
@ -0,0 +1,17 @@
|
||||
---
|
||||
title: "test-driven-development"
|
||||
tags:
|
||||
- cosc202
|
||||
---
|
||||
|
||||
# test-driven-development
|
||||
|
||||
tests are developed before the code
|
||||
|
||||
are a spec of what the code should do
|
||||
|
||||
first they fail ⇒ as you develop, they pass
|
||||
|
||||
+ quantifiable progress of code
|
||||
|
||||
> tests are not always bug free
|
||||
28
content/notes/testing.md
Normal file
28
content/notes/testing.md
Normal file
@ -0,0 +1,28 @@
|
||||
---
|
||||
title: "testing"
|
||||
tags:
|
||||
- cosc202
|
||||
---
|
||||
|
||||
# testing
|
||||
|
||||
- most software will contain bugs
|
||||
- bug severity if not always equivalent to bug priority
|
||||
- testing is seeking out bugs
|
||||
- some test types
|
||||
- unit tests
|
||||
- integration tests ⇒ check units work together
|
||||
- end-to-end tests ⇒ check behaviour of whole program
|
||||
|
||||
## 1 Limitations
|
||||
- testing every code path is impossible
|
||||
- halting problem - cant fully analyse code using code
|
||||
- proved by alan turing in 1936
|
||||
|
||||
- good test design focuses on _key cases_ to pass and fail
|
||||
- not probe interaction between units
|
||||
- this should be done by integration testing
|
||||
|
||||
- testing may afffect behaviour of code
|
||||
- testing framework may affect the order of esecution
|
||||
- testing framework may change execution speed
|
||||
89
content/notes/unit-testing.md
Normal file
89
content/notes/unit-testing.md
Normal file
@ -0,0 +1,89 @@
|
||||
---
|
||||
title: "unit-testing"
|
||||
tags:
|
||||
- cosc202
|
||||
---
|
||||
|
||||
# unit-testing
|
||||
|
||||
- divide code into units ⇒ test those units
|
||||
|
||||
- consider appropriate scale
|
||||
- depends on type of code project as well as language
|
||||
- object oriented: classes? methods?
|
||||
- procedural: functions? modules?
|
||||
|
||||
- test each unit independently
|
||||
- frequently
|
||||
- often after each commit/push
|
||||
- can run tests if parallel
|
||||
- may need to build environment in which tests run
|
||||
|
||||
### 0.1 supports useful principles
|
||||
can support complementary work by team members
|
||||
early discovery of problems
|
||||
can help with documentation and specification
|
||||
- unit tests can be a form of executable specification
|
||||
- helps team members understand requirements
|
||||
|
||||
### 0.2 Test environment
|
||||
consider code that interacts with a database
|
||||
- you cant let that code write to a real database
|
||||
- but you want to check that writes were performed
|
||||
|
||||
common solution is to create a fake database
|
||||
- class that mocs database operations
|
||||
- can also test error handling by returning error codes
|
||||
|
||||
mock up the database with a pretend model that returns fixed results to query
|
||||
- be careful not to mock up data base incorrectly
|
||||
|
||||
can be a pre-recorded interaction
|
||||
|
||||
### 0.3 Test life cycle
|
||||
- set up test environment
|
||||
- run test code
|
||||
- check results
|
||||
- aggregate results into test summary
|
||||
|
||||
simple test: run method ⇒ check value
|
||||
tests may chack that code fails appropriately
|
||||
- crash when expected
|
||||
- exceptions are generated
|
||||
|
||||
### 0.4 Language support
|
||||
language may have bilt in testing support
|
||||
- e.g., Go and Rust have command line tools to run tests
|
||||
|
||||
External tools can often work well too
|
||||
- e.g., java code annotations can mark tests
|
||||
- java ignores most annotations, but testing tools (JUnit) can use them
|
||||
- annotations are symbols that begin with @ in source code
|
||||
|
||||
we want to distinguish between tests and normal code
|
||||
- also should support for sqapping in/out mocking code
|
||||
|
||||
### 0.5 JUnit
|
||||
test classes have a particular filename pattern
|
||||
|
||||
annotate test methods with @Test
|
||||
|
||||
other annotations
|
||||
|
||||
- @BeforeAll and @BeforeEach (and after)
|
||||
- @RepeatedTest
|
||||
|
||||
JUnit 5 also supports dynamically generated tests
|
||||
|
||||
### 0.6 TestNG
|
||||
|
||||
based off JUnit and fixes some it it's problems
|
||||
|
||||
- provides control over threading
|
||||
- run tests in parallel
|
||||
- also tests for parallelism bugs
|
||||
- multithreaded code i hard to debug
|
||||
- data driven testing
|
||||
- also
|
||||
- integration testing
|
||||
- end to end testing
|
||||
Loading…
Reference in New Issue
Block a user