---
# System prepended metadata

title: 006 Internal

---

# 006 Internal

Theme: Testing for science, part 1

- introduction

- 10-15 Testing for Science
    - Run as a two-person discussion 
    - https://github.com/ResearchSoftwareHour/rsh-notes/issues/35
      - What makes a unit test a "good test"?
        - test one thing or several things in one test?
        - multiple asserts can lead to later asserts never to be tested
        - size of the unit to test
      - How to write good unit tests for more complicated functions than int fibonacci(int n)? For example, what if the return value of a function is random?
        - demo below
        - Radovan "how would you verify it as a human? how would you explain it to me over a telephone?"
        - sometimes I test a function comparing with a noddy but "obviously correct" function I wrote earlier
      - How to write unit tests for private class-member functions?
      - How to test e.g. functions that only print out some summary on the terminal?
        - maybe reformulate the function to be "pure" and return a "Maybe"
        - or use logging
        - one can also capture prints in Python
      - How to test the failure of functions, e.g. error messages, warnings.

- 10 Richard: pytest
    - quick demonstration
    - simple example of a deterministic function
        - celsius_to_farenheit
        - is testing 0 and 100 enough?
    - simple example of a probabilistic function
        - testing bounds, e.g. -10 <= x <= 10
        - fixture to seed the RNG
    - Should the tests be in the same file?

=== halftime===
- 5-10 Radovan: github actions
    - Deploy the previous demo to github-actions
    - comparison with travis
    - also mention GitLab CI, Appveyor, Circle CI

- 10 Radovan: Changing git history: `--amend`, `--fixup`, `--autosquash`
    - Why might we want to fix up history?
    - When *not* to fix up history?
    - `--amend`
    - `commit --fixup` and then `rebase -i --autosquash`

- 5 Richard: Blub paradox
    - https://en.wikipedia.org/wiki/Paul_Graham_(programmer)#The_Blub_paradox
    - Original source: http://www.paulgraham.com/avg.html
    - Definition of the paradox
    - When is it worth staying with the simpler solution?
        - time investment
        - number of contributors who can use it
        - ecosystem
    - When is it worth moving to more complex solutions?
    - How do you learn complex solutions, if you just need to "get stuff done"?
    - Examples:
        - docker and containers
        - moving from make to cmake
        - moving from one language to another

- conclusion
- epilogue discussion
    - Richard: commit messages starting with filename, opinions?


## Ideas


- Github actions: board game network finished
- 
    - board game networks example

- 10 What's a `#!` ?
    - Turning any script to an executable
    - #!python
    - #!/usr/bin/env python
    - #!make -f
    - #!
    - Next time: how to make a python scirpt suitable for this

- module -> script, __main__, argument parsing

- 5 minutes Radovan
    - probably shows Cicero unless I get an inspiration

- blub paradox



