Skip to content

Instantly share code, notes, and snippets.

@jeremy-donson
Last active February 10, 2022 17:07
Show Gist options
  • Save jeremy-donson/0014480c4760f7002e481dfd43f7a10c to your computer and use it in GitHub Desktop.
Save jeremy-donson/0014480c4760f7002e481dfd43f7a10c to your computer and use it in GitHub Desktop.
Test Driven Project Management In 2022

Test Driven Project Management (tdpm) In 2022


Table of Contents


Goals:

  • Review default and custom issue label schemes.

  • Design custom github project issue labels.

  • Design custom github project board columns.

  • Git + Github Workflow Diagramming Needs Support

    • From issues to pull requests, test-driven support on github is conspicuously absent.
  • Scroll To Top


Test Driven Overview

  • The beginner meta-pattern is { Red => FAIL, Orange => PASS, Green=> SUCCEED }

  • The expert meta-pattern is { Red => FAIL, Orange => SUCCEED, Green => REFACTOR }

  • We learn best by doing, and by teaching others to do for themselves.

  • All github project work starts with issues.

  • All testing compares expectations vs actual results. Match = success. No match = fail.

  • In all cases, testing sufficiency is the goal towards:

    • recovery
    • prevention => see mission critical prevention below
    • automation

Test Targets

  • Six testing targets:
    • new feature testing => UTF-8 character set support
    • new bug testing
    • regression testing
    • new release testing => requires open source license
    • ongoing doc testing => requires license => how do we test docs?
    • i18n testing

Test Types

How do we label issues to indicate that we:

  • need support (of what kinds)?
  • need more evidence (what kinds)?
  • are not reproducible?
  • are reproducible, yet inconsistently so?
  • are about docs, rather than tools?
  • are about i18n, rather than tools?
  • should first test on linux for authoritative options? => Windows issues and OSX issues are support issues
  • need a diagram?
  • need roadmap and/or work milestones?
  • need roadmap and/or team workflow milestones?
  • spans multiple projects?
  • has been reviewed and is ready for project board?
  • Needs explicit test?
  • Needs an owner
  • Neds a tech review / support.

We will have label sets to help us tag our issue remediation workflows.

  • Github Issue Labels Defaults:

    • bug
    • duplicate
    • enhancement
    • help wanted
    • invalid
    • question
    • wontfix
  • Github Project Board Column Defaults:

    • none
    • to do
    • in progress
    • done
  • ??: What are issue data points?

  • We will instead have label sets, starting with 'github-labels-defaults':

    • LABEL: ITEMS
    • issue stages: submitted, reviewed, accepted, assigned, backlogged, rejected
  • Where we can have issues automatically labeled by github actions, we will do so.


Why bash?

  • The following tools have changed very little in 20+ years:

    • bash: default shell in linux
    • git: distributed versioning tool created by Linus Torwalds, the inventor of linux
    • sql: database standards ( DCL + DDL + DML = SQL )
  • The best learning opportunities for test driven approaches depend upon carefully selected sample apps and scripts.

References

Often we need docs that are more than a single page. Site maps and tables of contents are extremely important to standardize on. This supports organized doc templating.

Custom pretty alias for this URL that you made here. Usually I add that to the top of the gist so we can distribute an informative link to others.

  • This gist tells us how to convert gists to github repos.
    • Are gist comments conserved?

Public gists support forks and comments like this one. I am working on animated svg support for terminal git and bash sessions. My next comment will try to demo a terminal git and bash session or two.

Our Initial Diagram Efforts:

## TITLE
- DESCRIPTION
- [Rich Document Link](https://tinyurl.com/gittest001)
---
### Table of Contents
- [Section 1](#section-1)
- [Section 2](#section-2)
- [Section 3](#section-3)

#### Section 1
- Item 1
  - Sub-item 1
  - Sub-item 2

#### Section 2

#### Section 3

#### Section 4


In Both Slack and Github:

  • Anchors start with #
  • People start with @

Github Markdown Code Block Formatting Examples...

Github Markdown (ghmd) Code: README.md

## TITLE
- DESCRIPTION
---
### Table of Contents
- [Prerequisites](#prerequisites)
- [SVG Animation Testing](#svg-animation-testing)
- [Learning Modes](#learning-modes)
- [References](#references)
---
#### Prerequisites
- Basic [Git Knowledge](https://git-scm.com/) is already translated into [many languages](many-languages.md).
- Consider best package installers for [Win](https://scoop.sh/) and [Mac OSX](https://brew.sh/)
  - Use those tools to install what we can, or just download installers instead.
- [Install](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) + [Configure Git](https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup)
- Install any ascii editor, preferably [VSCode](https://code.visualstudio.com/download).
- Install multiple browsers, including [Chrome](https://www.google.com/chrome/)[Firefox](https://www.mozilla.org/en-US/firefox/new/)[Apple Safari]()[Opera](https://www.opera.com/)
- We also have screen recording options using [Apple QuickTime](https://support.apple.com/downloads/quicktime).
- Install [termtosvg](https://nbedos.github.io/termtosvg/)

#### SVG Animation Testing
- Animation of terminal git + bash sessions.
- Terminal session recording tool at play: [termtosvg](https://nbedos.github.io/termtosvg/)
- Spot animation review and upload.
- Ensure terminal utf8 support.
- Consider i18n schemes.

#### Learning Modes
- Passive Trainees
- Active Trainees
- Live Training
- Automated Training
- Curriculum Design

#### References
- 
- [Open OS Window From Terminal](https://superuser.com/questions/116142/open-a-directory-in-a-linux-gui-file-browser-via-the-command-line)
---

Linux Default Shell (bash statements) Code: bash wtf.sh

$ echo $SHELL                # What shell am I in?
$ bash --version             # What bash version is installed?
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin19)
Copyright (C) 2007 Free Software Foundation, Inc.
$ pwd                        # Where am I?
$ ls                         # What dirs do I see there?
$ echo $PATH                 # What executable paths do I have configured?
$ which bash                 # Where is this bash binary installed?
$ history                    # What bash statements have executed in the past?   
$ history | grep echo        # What bash statements have executed which include the echo command?
$ bash                       # Open a new bash sub-shell...
$ mkdir -p ~/repos/; cd $_   # Create local repos dir if it does not exist and cd there.
  • To support most available operating systems:

    • On OSX, we have the open command, which opens a finder window from the terminal: $ open .
    • On Windows, we have the start command, which opens explorer window from terminal: $ start .
    • On Linux, Gnome explorer window from terminal is opened via: $ nautilus .
    • On Linux, other file explorer window from terminal is opened via: $ xdg-open .
  • We tile the following minimal windows to make sure we can see everything without mousing around.

  • tiled-windows

  • OSX Finder Desktop recording goes here!!

  • Linux git + bash commands: $ bash git-101.sh

$ git version                                             # Version 2.x is required.
git version 2.24.3 (Apple Git-128)
$ git config --list --show-origin                         # Review current git settings.
$ git config --list --show-origin | egrep "user.email"    # In particular, contributor email must match github profile.
$ mkdir -p ~/repos/local-git-repo-01/; cd $_              # Create local repos workspace.  Create new empty dir that will become git repo.
$ git status
$ git init                                                # This creates a .git/ folder, under where all version info and data is stored.
$ git status
$ mkdir subdir/
$ git help -a > git-help-a.txt
$ git help -g > subdir/git-help-g.txt
$ git status
$ git add .
$ GITHUB_ISSUE_ID=''
$ LOG_MESSAGE='This is my first commit in my first local git repo.'
$ COMMIT_MESSAGE="${GITHUB_ISSUE_ID}: ${LOG_MESSAGE}"
$ git commit -m "${COMMIT_MESSAGE}"

  • Next we will start to learn to do this in a test-driven way using bash on linux.

    • The code of every programming lanaguage can be versioned with git.
    • Every programming language supports this approach.
  • Git Commands Jumpstart

    • git (for windows) install
    • git commands:
    • help
    • version
    • status
    • configure
    • init
    • add
    • commit
    • log
  • To complete Solo Local Git, the following ought to be reviewed and tried.....

    • .gitignore
    • diff
    • patch
    • remote
    • ssh key
    • clone
    • desktop apps
    • multi-factor auth (MFA)
    • git hooks
    • brief history of git
    • open source software
    • open source software companies
    • github + gitlab + bitbucket

Test-Driven Git + Github Workflows

  • Bash Code To Test Bash Code: INPUT_CODE OUTPUT_EXPECTED
$ CODE_TEXT_01='# CODE LINE GOES HERE!!'
$ echo "${CODE_TEXT_01}"
$ FILE='greetings-bash.sh'
$ TARGET_OUTPUT="Greetings bash."
$ echo -e "${CODE_TEXT}" > $FILE ; chmod 777 $FILE
$ ACTUAL_OUTPUT=$( bash ${FILE} )
$ echo -e "${ACTUAL_OUTPUT}"
$ if [ "${ACTUAL_OUTPUT}" -eq "${TARGET_OUTPUT}" ]; then echo "SUCCESS";   else echo "FAILURE";   fi

# What would we expect thus far?
$ CODE_TEXT_02='/* CODE LINES\nGO HERE!!*/'
$ CODE_TEXT_03='Greetings bash.'
$ CODE_TEXT_04=$( echo "Greetings $0" > $FILE)
$ CODE_TEXT_05=$( echo 'echo -e "Greetings $0"' > $FILE)

# Can we target expected output with hard-coded input to verify that the test works?

# What happens if our bash variables are not assigned values?
# Would default values help?  How about a log?
$ LOGFILE='greetings-x.log' #  Sample log row: [ id :  ]
# Can we test for those variables instead of finding problem with them?  Is that standard tool ops or --debug mode?
# Would a test case id, name and log entries help?

https://unix.stackexchange.com/questions/232384/argument-string-to-integer-in-bash/232386

# Can we test other programming language execution output this way?

echo $SHELL echo $0

Test-Driven Git Across Programming Language

  • Language-Agnostic Implementations
  • Here we take the greetings-x.sh script idea to the next level.

Table of Contents


Generic Patterns

  • Gather Values: bash LANGUAGE="$SHELL" ; LANG_VERSION=$( bash --version | grep -i gnu | cut -d' ' -f4 | cut -d'-' -f1 ) ; YEAR=$( date '+%Y' ); OS=$( python3 -m platform 'print(system())' ) ;

  • Target Output: OUTPUT="Greetings ${LANGUAGE} at ${LANG_VERSION} in current year ${YEAR}.\nRunning on OS ${FLAVOR} ${DISTRO} ${VERSION}."; echo "${OUTPUT}"

Programming Languages

Tools Per Programming Language Matrix

  • Installation: Source, Methods, Version [ legacy, current, emerging ]
  • Package Managers
  • Single and Multi-Line Comments
  • Virtual Environments
  • Testing Tools
  • Other Utilities

Language Agnostic Implementations


Operating Systems + Package Managers For Linuxification

  • RedHat => yum
  • Ubuntu => apt
  • Apple OSX => brew
  • Windows => scoop or chocolatey of GitForWindows
  • Debian => ??
  • iOS => ??
  • Android => ??

Database Management Systems

  • SQL

    • postgresql
    • sqlserver
    • mysql
    • oracle
    • sqlite
    • aws batch
  • NoSQL

    • Redis
    • spark
  • graphDBs

  • Database Admin: Versions [+Engines] --< Recipes --< Ingredients --< Tasks

    • Backup Operating System Securely (BOSS) as Infrastructure As Code (IAC)

    • Backup Database Management System as Service As Code (SAC)

    • Backup Data => Max Granularity + Min Restore Times

    • Create Replica

    • Restore Data

    • Data Designer Tools

    • Configuration Files

      • Read-optimized
      • Write-optimized
      • Failover
    • Roles + Packages

    • Data Control Language

      • Security
        • Network
        • Operating System
        • Storage
        • Data
    • Data Definition Language

      • Create [ Tablespace + Schema + Table + View + Function + Procedure + Script ]
      • Data Types
        • Data Subtypes
    • Data Manipulation Language

    • Stored Routines [ functions + procedures + triggers ] + Packages

    • Shell scripts

    • DBMS scripts

    • Show variables

    • Show status

    • show processlist | [grep "$X" | ] Count

    • Enable Logs

    • Parse Logs

    • Replication Recipes

  • Tools

    • sysbench
    • linux
    • httpload
    • netstat
    • iostat
    • sqlproxy
    • df
    • du
    • free
    • nano
    • git
    • curl
    • telnet
    • wget
    • dig
    • arp
    • qperf
  • Text Data

    • binary
    • ascii
      • csv
      • json
      • yaml

Cloud Services

  • Public : Private
  • Managed : Custom : Hybrids
  • VPC --< [ Network + Compute + RAM + GPU + Storage ]
  • On-demand infrastructure provisioning
  • Scheduled + cost-optimized infrastructure provisioning

Open Source Vendors

Git Book Translation Links

  • "Pro Git" book is available online free in English. Screen Shot 2022-02-08 at 12 50 34 AM

  • Other translations are listed below.



Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment