Added Cobra for the Command Line Interface

[lonnblad]

• Added the CLI framework Cobra
• Broke down the godog CLI into subcommands:
  • build
  • help
  • run
  • version

> godog help

> godog help run

> godog --help (godog v0.10.0)

[codecov]

Codecov Report

Merging #321 into master will increase coverage by 0.09%.
The diff coverage is 84.61%.

@@            Coverage Diff             @@
##           master     #321      +/-   ##
==========================================
+ Coverage   79.93%   80.03%   +0.09%     
==========================================
  Files          23       25       +2     
  Lines        2218     2254      +36     
==========================================
+ Hits         1773     1804      +31     
- Misses        342      347       +5     
  Partials      103      103              

Impacted Files	Coverage Δ
flags_deprecated.go	93.80% <ø> (ø)
internal/builder/builder.go	62.67% <ø> (ø)
run.go	81.88% <0.00%> (ø)
flags_v0110.go	50.00% <50.00%> (ø)
internal/flags/flags.go	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e6223ba...722d97b. Read the comment docs.

[aslakhellesoy]

What's the motivation of having a command-based CLI as opposed to an option-based one?

[lonnblad]

What's the motivation of having a command-based CLI as opposed to an option-based one?

@aslakhellesoy
Separation of concern and structure mainly.

If you now would execute > godog --format progress vs. > godog --format progress --output godog.test.
A binary would be created in the second example, while in the first example, a binary would first be created and then executed, running the testcases with the progress formatter.
A detail is that, if you after the second example, would execute > ./godog.test, you would not get the progress formatter, because the binary requires its own set of options, so you would have to execute it like: > ./godog.test --format progress.

There have also been previous discussions here to build a function that checks the gherkin and the registered step definitions, which would fit well into the sub-command structure as well, maybe as an fmt or validate command.

When starting out with godog and gherkin, I would have liked to see something like > godog init, which would have created a basic godog structure to get people started. The getting started document would then more or less be:

Initialize a go module for the godog example:
  > go mod init godog-example
Install godog:
  > go get github.com/cucumber/godog/cmd/godog@v0.10.0
Create a simple example:
  > godog init --example
Run the example:
  > godog run

For people that are used to using the go binary, there are two different solutions that solve a similar problem:
> go build main.go vs > go run main.go, where build builds a binary from main.go and run both builds and then executes it.
> go test . vs go test -c ., where the first builds and executes the tests, while -c builds a binary.

[lonnblad]

@aslakhellesoy what do you think?

[titouanfreville]

Love this feature 👍