diff --git a/content/notes/07-testing.md b/content/notes/07-testing.md new file mode 100644 index 000000000..ef7587f9c --- /dev/null +++ b/content/notes/07-testing.md @@ -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 diff --git a/content/notes/08-debugging.md b/content/notes/08-debugging.md new file mode 100644 index 000000000..c55b49c33 --- /dev/null +++ b/content/notes/08-debugging.md @@ -0,0 +1,9 @@ +--- +title: "08-debugging" +tags: +- cosc202 +--- + +# 08-debugging + +[[debugging]] diff --git a/content/notes/09-documentation.md b/content/notes/09-documentation.md new file mode 100644 index 000000000..ca3cb6767 --- /dev/null +++ b/content/notes/09-documentation.md @@ -0,0 +1,9 @@ +--- +title: "09-documentation" +tags: +- cosc202 +--- + +# 09-documentation + +[[documentation]] diff --git a/content/notes/10-continuous-integration-1.md b/content/notes/10-continuous-integration-1.md new file mode 100644 index 000000000..bf182528c --- /dev/null +++ b/content/notes/10-continuous-integration-1.md @@ -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 \ No newline at end of file diff --git a/content/notes/11-continuous-integration-2.md b/content/notes/11-continuous-integration-2.md new file mode 100644 index 000000000..bbc207c60 --- /dev/null +++ b/content/notes/11-continuous-integration-2.md @@ -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 +![](https://i.imgur.com/whU7QoF.png) : 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 + +![](https://i.imgur.com/02eqv7A.png) + +![](https://i.imgur.com/RaeYc1I.png) : 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 + +![](https://i.imgur.com/XtCap0P.png) +![](https://i.imgur.com/W2xBi4d.png) diff --git a/content/notes/continuous-integration.md b/content/notes/continuous-integration.md index 0b51b3aec..0620d4dc6 100644 --- a/content/notes/continuous-integration.md +++ b/content/notes/continuous-integration.md @@ -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 diff --git a/content/notes/debugging.md b/content/notes/debugging.md new file mode 100644 index 000000000..fa5ffbd1a --- /dev/null +++ b/content/notes/debugging.md @@ -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 diff --git a/content/notes/documentation.md b/content/notes/documentation.md new file mode 100644 index 000000000..9d01f5803 --- /dev/null +++ b/content/notes/documentation.md @@ -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 diff --git a/content/notes/test-driven-development.md b/content/notes/test-driven-development.md new file mode 100644 index 000000000..e18719129 --- /dev/null +++ b/content/notes/test-driven-development.md @@ -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 diff --git a/content/notes/testing.md b/content/notes/testing.md new file mode 100644 index 000000000..72b1983bd --- /dev/null +++ b/content/notes/testing.md @@ -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 diff --git a/content/notes/unit-testing.md b/content/notes/unit-testing.md new file mode 100644 index 000000000..048260cd0 --- /dev/null +++ b/content/notes/unit-testing.md @@ -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 \ No newline at end of file