Skip to content

Test automation tool to assist running something, and checking something, then reporting something; when you commit something.

Notifications You must be signed in to change notification settings

BradleyA/git-TEST-commit-automation

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 

Repository files navigation

git-TEST-commit-automation Release Status

GitHub Release GitHub Release Date GitHub Commits Since GitHub Last Commits

Open GitHub Issue GitHub Open Issues GitHub Closed Issues GitHub pull requests GitHub pull requests

GitHub Repo Clones GitHub Repo Views GitHub Size Language Bash MIT License

Goal

Test automation tool to assist running something, and checking something, then reporting something; when you commit something.

If you like this repository, select in the upper-right corner, GitHub stars, thank you.

Table of content



Description

After entering the following command:

git commit -m 'latest changes' <COMMIT_FILE_NAME>

Git runs any Git hooks found in <REPOSITORY-NAME>/.git/hooks/ directory. Git hooks are scripts that Git executes before and/or after events. Two local Git hooks are included with git-TEST-commit-automation (pre-commit, post-commit).

pre-commit creates a file (${REPOSITORY-NAME}/hooks/COMMIT_FILE_LIST) which includes file(s) that are commited.

post-commit searches for a TEST/<filename>/ sub-directory where the commited filename is located. If the sub-directory is found post-commit runs TEST/<filename>/SA-setup.sh and/or TEST/<filename>/FVT-setup.sh then searches for files beginning with SA- of FVT- and runs them.

Why did I create git-TEST-commit-automation when there are so many great open software and enterprise level testing solutions available. I needed something that would

  • run some basic Static Analysis Tests (SA) and Funciotnal Verification Tests (FVT) with minimal learning curve
  • inform, not impede code development
  • encourage 'git commit -m 'message', not exit 1 if there is any code incident
  • allows basic test cases to be included with code in any Git repository
  • could be setup, updated, and uninstall without effecting the code being developed
  • support adding other test solutions to this solution with minimal changes

TL;DR - During code design, a software developer's focus is on how to solve parts of a bigger solution. A developer may throw out a couple to dozens of lines of code. It did not matter that those lines of code did or didn't meet every test requirement. As a design matures it is increasingly important to have code PASS tests. It is also important for a developer to design SA and FVT test cases for their new code. At that time their code is ready for additional testing using open software and enterprise level testing solutions.

Return to top

Test Case Types

Funciotnal Verification Test (FVT) is defined as the process of verifying that the design meets its specification from a functional perspective. ... Functional verification establishes that the design under test (DUT) implements the functionality of the specification correctly.

Static Analysis (SA) is the examination of code prior to the program’s execution SA is code analysis, syntax, permission, code inspection, code review, etc.

Return to top

Objectives

  • Quick setup with default test cases for any Git repository (in seconds)
  • Quick uninstall from any Git repository
  • Quick check of test case depth for a file (option -f) and all files for any Git repository (option -a)
  • Quick setup of default SA- test cases for a file (options --filename sample.sh --add)
  • Quick upgrade of default test cases and git-TEST-commit-automation commands (git-setup-TEST-cases.sh)
  • Quick reduction of untracked TEST case files (option -c)

Return to top

Quick Start Tutorials

Return to top

Command Descriptions

pre-commit

  • Creates <REPOSITORY-NAME>/hooks/COMMIT_FILE_LIST with a list of <REPOSITORY-NAME>/<FILE> being committed.

post-commit

  • Loop through committed files found in <REPOSITORY-NAME>/hooks/COMMIT_FILE_LIST
  • if COMMIT_FILE has a <REPOSITORY-NAME>/<PATH>/TEST/<COMMIT_FILE>/' directory run FVT-setup.sh and/or SA-setup.sh
  • Loop through and run <REPOSITORY-NAME>/<PATH>/TEST/<COMMIT_FILE>/SA-<TEST_CASE> and/or FVT-<TEST_CASE>
  • Report output as PASS or FAIL or ERROR, through stdout . . . some methed will notify someone of the results. (not sure which method is going to work for me and you? . . . stdout, logs-scrape, tables, email, twitter, slack, call a friand, etc.)

git-set-env-for-manual-test.sh

  • sets EXAMPLES_DIRECTORY and REPOSITORY_DIR_COUNT environment variables to manually test TEST cases

git-setup-TEST-cases.sh

  • setup and update git-TEST-commit-automation in <REPOSITORY-NAME>/hooks/ directory of current Git repository

git-TEST-cases.sh

  • lists and manages files in TEST/<COMMIT_FILE>/ directories in current Git repository

git-uninstall-TEST-cases.sh

  • uninstall git-TEST-commit-automation in <REPOSITORY-NAME>/hooks/ and <REPOSITORY-NAME>/TEST/<COMMIT_FILE>/ directories of current Git repository

ARCHITECTURE TREE

/usr/local/bin/                           <-- <BIN_DIR>
├── git-set-env-for-manual-test.sh
├── git-setup-TEST-cases.sh
├── git-TEST-cases.sh
└── git-uninstall-TEST-cases.sh

Return to top

hooks directory The <REPOSITORY-NAME>/hooks directory was created for two reasons. 1) all git-TEST-commit-automation files are in one location to allow for quick removal without effecting other <REPOSITORY-NAME>/ files. 2) the default <REPOSITORY-NAME>/.git/hooks/files are not tracked and I wanted to track changes. A symbolic link from <REPOSITORY-NAME>/.git/hooks to this <REPOSITORY-NAME>/hooks directory that are managed in this repository using markit.

Place the expected results from the test case into a file with the same test case name but add '.expected' ('dot'expected). Pipe the output from the test case into a file with the same name but add '.test-case-output'.

Return to top

Future Objectives

WARNING: These instructions are incomplete. Consider them as notes quickly drafted on a napkin rather than proper documentation!

  • <COMMIT_FILE_NAME>.test-case-input - Add support #12

  • Design for quick test case git branch merge (include steps)

  • Quick test case branch merge from test team's custom test cases without merge conflicts (include steps)

    git remote --verbose
    git remote add origin https://github.com/BradleyA/git-TEST-commit.git
    git remote --verbose
    git push -u origin master
    
    git-TEST-cases.sh -c --hooks
    
    git branch -a
    git branch git-TEST-commit-#1
    
    git push origin git-TEST-commit-#1
    git branch -a
    
    #  create a branch
    git pull                      #  get latest pushed commits
    git checkout -b development   #  create development branch
    git push --set-upstream origin development   #  create github development branch upstream (github)
      #  or
    git push -u origin development
      #  write code in development branch
      #  create README on github master branch
    git pull origin master        #  pull chnages to master bransh to development bransh
      #  write code in development branch
    
    • challenge is SA-setup.sh & FVT-setup.sh could be changed by development and test teams
    • Quick backup of all test cases in repository (<FILE-NAME>.tar) (code is in uninstall-) (option: --backup --restore)
    • Include support for other test or CI solutions ... Scan for Credentials, BATS, Travis CI, ...

Return to top

  • Rquirements:
    • Linux
    • git
    • Internet access to GitHub

Contribute

Please do contribute! Issues, comments, and pull requests are welcome. Thank you for your help improving software.

Return to top

Author

Follow @bradleyaustintx GitHub followers

Return to top

Stars

Stargazers repo roster for @BradleyA/git-TEST-commit-automation

Return to top

Forks

Forkers repo roster for @BradleyA/git-TEST-commit-automation

Return to top

Tested OS

  • Raspbian GNU/Linux 10 (buster)
  • Ubuntu 14.04.3 LTS (amd64,armv7l)
  • Ubuntu 16.04.7 LTS (amd64,armv7l)
  • Ubuntu 18.04.5 LTS (amd64,armv7l)

Return to top

Design Principles

  • Have a simple setup process and a minimal learning curve
  • Be usable as non-root
  • Be easy to install and configure

Return to top

License

MIT License

Copyright (c) 2020 Bradley Allen

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Return to top