octoleo
/
telegram-bot-bash
mirror of https://github.com/octoleo/telegram-bot-bash.git
1
1
Fork 0
Code Issues Projects Releases Wiki Activity

adjust test doc

This commit is contained in:
Kay Marquardt (Gnadelwartz) 2019-05-01 12:37:18 +02:00
parent bcbff7f865
commit 2344f3237d
3 changed files with 44 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

57
doc/7_develop.md
View File

@ -10,7 +10,7 @@ bashbot development is done on github. If you want to provide fixes or new featu
2. setup your [environment for UTF-8](4_expert.md#Setting-up-your-Environment)
3. clone your bashbot fork to a new directory ```git clone https://github.com/<YOURNAME>/telegram-bot-bash.git```, replace ```<YOURNAME>``` with your username on github
4. create and change to your develop branch ```git checkout -b <YOURBRANCH>```, replace ```<YOURBRANCH>``` with the name you want to name it, e.g. 'develop'
5. give your (dev) fork a new version tag: ```git tag vx.xx```, version must be higher than current version
5. give your (dev) fork a new version tag: ```git tag vx.xx```(optional)
6. setup github hooks by running ```dev/install-hooks.sh``` (optional)
### Test, Add, Push changes
@ -20,10 +20,10 @@ A typical bashbot develop loop looks as follow:
2. after changing a bash sript: ```shellcheck -x scipt.sh```
3. ```dev/all-tests.sh``` - *in case if errors back to 2.*
4. ```dev/git-add.sh``` - *check for changed files, update version string, run git add*
5. ```git commit' -m "COMMIT MESSAGE"; git push```
5. ```git commit -m "COMMIT MESSAGE"; git push```
**If you setup iyou dev environment with hooks and use the scripts above, versioning, addding and testing is done automatically.**
**If you setup your dev environment with hooks and use the scripts above, versioning, addding and testing is done automatically.**
### Prepare a new version
After some development it may time to create a new version for the users. a new version can be in sub version upgrade, e.g. for fixes and smaller additions or
@ -36,19 +36,20 @@ Usually I start with pre versions and when everything looks good I push out a re
### Versioning
Bashbot is tagged with version numbers. If you start a new development cycle you must tag your fork with a version higher than the current version.
Bashbot is tagged with version numbers. If you start a new development cycle you can tag your fork with a version higher than the current version.
E.g. if you fork 'v0.60' the next develop version should tagged as ```git tag "v0.61-dev"``` for fixes or ```git tag "v0.70-dev"``` for new features.
To get the current version name of your develepment fork run ```git describe --tags```. The output looks like ```v0.70-dev-6-g3fb7796``` where your version tag is followed by the number of commits since you tag your branch and followed by the latest commit hash. see also [comments in version.sh](../dev/version.sh)
To update the Version Number in your scripts run ```dev/version.sh```, it will update the line '#### $$VERSION$$ ###' in all files to the current version name.
To update the Version Number in files run ```dev/version.sh files```, it will update the line '#### $$VERSION$$ ###' in all files to the current version name.
To update version in all files run 'dev/version.sh' without parameter.
### Shellchecking
### Shellcheck
For a shell script running as a service it's important to be paranoid about quoting, globbing and other common problems. So it's a must to run shellchek on all shell scripts before you commit a change. this is automated by a git hook activated in Setup step 6.
In addition you can run ```dev/hooks/pre-commit.sh``` every time you want to shellcheck all files given in 'dev/shellcheck.files'.
To run shellcheck for a single script run ```shellcheck -x script.sh```, to check all schripts run ```dev/hooks/pre-commit.sh```.
## bashbot tests
@ -56,20 +57,44 @@ Starting with version 0.70 bashbot has a test suite. To start testsuite run ```d
### enabling / disabling tests
All tests are placed in the directory ```test```. To disable a test remove the x flag from the '*-test.sh' test script, to (re)enable a test make the script executable again.
All tests are placed in the directory ```test```. To disable a test remove the execute flag from the '*-test.sh' script, to (re)enable a test make the script executable again.
### creating new tests
To create a new test run ```test/ADD-test-new.sh``` and answer the questions, afterwards you have the following described files and dirs:
To create a new test run ```test/ADD-test-new.sh``` and answer the questions, it will create the usually needed files and dirs:
Each test consists of a script script named like ```p-name-test.sh``` *(where p is test pass 'a-z' and name the name
Each test consists of a script script named after ```p-name-test.sh``` *(where p is test pass 'a-z' and name the name
of your test)* and an optional dir ```p-name-test/``` *(script name minus '.sh')* for additional files.
The file ```ALL-tests.inc.sh``` must be included from all tests, do not forget the shellcheck source directive to statisfy shellcheck.
Tests with no dependency to other tests will run in pass 'a', tests which need an initialized bahsbot environment must run in pass 'd' or later.
If '$1' is present the script is started from 'ALL-tests.sh' and a temporary test environment is setup in directory '$1'.
The temporary test environment is created when 'ALL-tests.sh' starts and deleted after all tests are finished.
A temporary test environment is created when 'ALL-tests.sh' starts and deleted after all tests are finished.
The file ```ALL-tests.inc.sh``` must be included from all tests and provide the test environment as shell variables:
```bash
# Test Evironment
TESTME="$(basename "$0")"
DIRME="$(pwd)"
TESTDIR="$1"
LOGFILE="${TESTDIR}/${TESTME}.log"
REFDIR="${TESTME%.sh}"
TESTNAME="${REFDIR//-/ }"
# common filenames
TOKENFILE="token"
ACLFILE="botacl"
COUNTFILE="count"
ADMINFILE="botadmin"
DATADIR="data-bot-bash"
# SUCCESS NOSUCCES -> echo "${SUCCESS}" or echo "${NOSUCCESS}"
SUCCESS=" OK"
NOSUCCESS=" FAILED!"
# default input, reference and output files
INPUTFILE="${DIRME}/${REFDIR}/${REFDIR}.input"
REFFILE="${DIRME}/${REFDIR}/${REFDIR}.result"
OUTPUTFILE="${TESTDIR}/${REFDIR}.out"
```
Example test
```bash
@ -80,11 +105,11 @@ Example test
# shellcheck source=test/ALL-tests.inc.sh
source "./ALL-tests.inc.sh"
if [ -f "bashbot.sh" ]; then
if [ -f "${TESTDIR}/bashbot.sh" ]; then
echo "${SUCCESS} bashbot.sh exist!"
exit 0
else
echo "${NOSUCCESS} bashbot.sh missing!"
echo "${NOSUCCESS} ${TESTDIR}/bashbot.sh missing!"
exit 1
fi
```

2
examples/README.md
View File

@ -27,7 +27,7 @@ Background jobs are an easy way to provide sceduled messages or alerts if someth
**Note:** Output of system commands often contains newlines, each newline results in a telegram message, the function 'send_telegram' in
mycommands.sh avoids this by converting each newline to ' mynewlinestartshere ' before output the string.
### Ssystem Status
### System Status
**send-system-status** contains an example for commands showing status of different subsystems. This example is adapted from
https://github.com/RG72/telegram-bot-bash to current bashbot commands, but not fully tested. This will show how easy you can

3
test/b-example-test.sh
View File

@ -1,5 +1,6 @@
#!/usr/bin/env bash
# file: b-example-test.sh
#### $$VERSION$$ v0.70-rc1-0-g8883cc9
# include common functions and definitions
# shellcheck source=test/ALL-tests.inc.sh
@ -9,7 +10,7 @@ if [ -f "${TESTDIR}/bashbot.sh" ]; then
echo "${SUCCESS} bashbot.sh exist!"
exit 0
else
echo "${NOSUCCESS} bashbot.sh missing!"
echo "${NOSUCCESS} ${TESTDIR}bashbot.sh missing!"
exit 1
fi