Test automation tool to assist running something, and checking something, then reporting something; when you commit something.
- Description
- Test Case Types
- Objectives
- Quick Start Tutorials
- Command Descriptions
- ARCHITECTURE TREE
- Future Objectives
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.
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.
- 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)
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
/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
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'.
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, ...
- Rquirements:
- Linux
- git
- Internet access to GitHub
Please do contribute! Issues, comments, and pull requests are welcome. Thank you for your help improving software.
- 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)
- Have a simple setup process and a minimal learning curve
- Be usable as non-root
- Be easy to install and configure
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.