new subcommand: bashly test

[meleu]

Request

This is a 2-in-1 request:

1. provide a test_command setting accepting a string (default is nil)
2. add a bashly test subcommand that does this:
   1. bashly build --env development
   2. run whatever is in the test_command with the arguments given to bashly test

Example: bashly test --some-option path/to/my-test-file would act like I called these commands:

bashly build --env development
${test_command} --some-option path/to/my-test-file
#  👆 obtained from bashly-settings.yml

If test_command is an empty string or nil, bashly test reports an error. Or even better: check if test_command is in the $PATH or is a path to an existing executable file.

Motivation

When I'm in the coding/testing cycle, here's what happen sometimes:

# change some code...

bats test/my-tests.bats
# 😕 become confused with weird results
# 🤦‍♂️ realize I forgot to `bashly build`

bashly build
bats test/my-tests.bats
# 👍 check actual results 

Of course I can solve this with a shell alias or something, but thought that a bashly test subcommand would also be nice.

[pcrockett]

I dunno, this sounds like what Makefiles (or similar) were created for. Ex:

# in Makefile

test: my_script
	bats tests/my-tests.bats
.PHONY: test

my_script:
	bashly build

So a simple make test would build your script if it were outdated, or just run your tests if it is up-to-date.

[DannyBen]

This does not sit well with me (although as always, I am open to be convinced otherwise).

Here are my top (but probably not only) reasons why:

1. The proposed bashly test is a wrapper around just two commands, and both commands might need to be customized. For example, I do just bashly generate --upgrade, someone else might use --env development and so on. Of course the second command is a complete wildcard and bashly itself has no knowledge of how to run it.
2. bashly test --some --arbitrary flags will not work. This is a "problem" of all command line tools. All flags will be considered an option for bashly test and therefore, it will exit with error. The only way this becomes viable is with the double dash notation: bashly test -- --flags --to be forwarded - which already lost its "shortcut" charm.
3. This is what task runners / build tools / makefile-alternatives are for. Personally, I use two of my own home made runners:
   • Runfile - for example, as can be seen in bashly itself, or a simpler (single file) use case here
   • opcode - for example, as can be seen in my bash scripts; Rush, opcode, git-changelog and others.
4. If we do bashly test it is a slippery slope. What about bashly build-docs and bashly deploy for example?

[meleu]

Good point guys.

There are already well-established UNIX ways to solve the kind of issue I described.

I think I'm too biased because of the Rails workflow (which is not necessarily good).

Closing this one.