Gain insights into writing professional command-line programs in Go. Delve into structuring Go programs, writing idiomatic code, testing effectively, and impressing users and managers.

write professional command  - line programs in Go.png

data.tar.gz

Go run main.go

Run main.sh

Run go test

Run go test2

GoLive

GoLiveTesting

Multi-git-Custom

Pre+main-v0.2

Main_to_cmd

Run go test-Coverage

Ginkgo

Ginkgo-BDD

Ginkgo-e2e

Cobra

Cobra-NoInstall

Cobra-NoInstall-FullApp

Final_Cobra_Multi-git

Viper

Viper-etcd

Viper-Cobra

SelfUpdating

Make

Special build

Embedding_Data

Go run main.go-Simple

In this course you will learn why Go is an awesome language for writing command-line programs. You will learn how to structure your Go programs, how to write idiomatic Go code, how to test your programs and how to amaze your users, peers and managers. 

The focus is on command-line programs in order to keep the course down to earth, but most of the principles and best practices you will learn apply to any Go program.

Write Professional Command-line Programs in Go

## Locating end-to-end tests

In Go, unit tests reside in the directory of the package they test. Where should you put end-to-end tests? For a command-line program like multi-git that has a single command called `mg` in the `cmd` directory, it makes sense to place the end-to-end tests there:

```
├── multi-git
│   ├── cmd
│   │   └── mg
```

However, I think of end-to-end tests as a separate entity that is not embedded with the code it is testing. The whole concept of black-box testing and testing from the outside suggests that testing in different locations is better. Also, in larger systems, there will be many artifacts, services, applications, tools, and commands that require end-to-end tests.

The complete set of end-to-end tests also represent all the meaningful ways to interact with the system. It is convenient for the purposes of learning, documentation, and auditing if all these tests are located in a central location. Finally, it's quite a mouthful to say "end-to-end tests" again and again. A common shorthand, which we’ll use from now on, is "e2e". Now, we'll place all our e2e tests in a top-level directory called `e2e_tests`:

```
├── multi-git
│   ├── LICENSE
│   ├── README.md
│   ├── cmd
│   ├── e2e_tests
│   ├── go.mod
│   ├── go.sum
│   └── pkg
```

## Building the foundation for e2e tests

With all the preliminaries out of the way, we can start with a skeleton for end-to-end tests. For multi-git, it's fine to have a single e2e test. We will use Ginkgo and Gomega for our e2e test just like we did for the unit tests. Here is the directory structure:

```
├── multi-git
│   ├── e2e_tests
│   │   ├── e2e_suite_test.go
│   │   └── multi_git_test.go
```

The multi_git_test.go file contains the infrastructure and test cases. In the e2e_tests package, it imports Ginkgo, Gomega, and our very own helpers package as well the `os` and `strings` packages from the standard library

```
package e2e_tests

import (
    . "github.com/onsi/ginkgo"
    . "github.com/onsi/gomega"
    . "github.com/the-gigi/multi-git/pkg/helpers"
    "os"
    "strings"
)
```

It also defines a constant for the base directory and a variable for the list of repos.

```
const baseDir = "/tmp/test-multi-git"

var repoList string
```

The `removeAll()` function is identical to the function from the unit tests and removes the base directory completely. It can be argued it should be moved to the helpers package. The BeforeEach function, which is called before every test, calls `removeAll()` and then rec-creates the base directory from scratch. Therefore, before each test, we start with an empty base directory.

After all the tests finish, the AfterSuite is called once, and the program calls `removeAll()` to clean up the base directory.

```
var _ = Describe("multi-git e2e tests", func() {
    var err error

    removeAll := func() {
        err = os.RemoveAll(baseDir)
        Ω(err).Should(BeNil())
    }

    BeforeEach(func() {
        removeAll()
        err = CreateDir(baseDir, "", false)
        Ω(err).Should(BeNil())
    })

    AfterSuite(removeAll)
```

Check out the `e2e_tests` directory and the files it contains in the application below:

# Locating end-to-end tests

In Go, unit tests reside in the directory of the package they test. Where should you put end-to-end tests? For a command-line program like multi-git that has a single command called `mg` in the `cmd` directory, it makes sense to place the end-to-end tests there:

```
├── multi-git
│   ├── cmd
│   │   └── mg
```

However, I think of end-to-end tests as a separate entity that is not embedded with the code it is testing. The whole concept of black-box testing and testing from the outside suggests that testing in different locations is better. Also, in larger systems, there will be many artifacts, services, applications, tools, and commands that require end-to-end tests.

The complete set of end-to-end tests also represent all the meaningful ways to interact with the system. It is convenient for the purposes of learning, documentation, and auditing if all these tests are located in a central location. Finally, it's quite a mouthful to say "end-to-end tests" again and again. A common shorthand, which we’ll use from now on, is "e2e". Now, we'll place all our e2e tests in a top-level directory called `e2e_tests`:

```
├── multi-git
│   ├── LICENSE
│   ├── README.md
│   ├── cmd
│   ├── e2e_tests
│   ├── go.mod
│   ├── go.sum
│   └── pkg
```

# Building the foundation for e2e tests

With all the preliminaries out of the way, we can start with a skeleton for end-to-end tests. For multi-git, it's fine to have a single e2e test. We will use Ginkgo and Gomega for our e2e test just like we did for the unit tests. Here is the directory structure:

```
├── multi-git
│   ├── e2e_tests
│   │   ├── e2e_suite_test.go
│   │   └── multi_git_test.go
```

The multi_git_test.go file contains the infrastructure and test cases. In the e2e_tests package, it imports Ginkgo, Gomega, and our very own helpers package as well the `os` and `strings` packages from the standard library

```
package e2e_tests

import (
    . "github.com/onsi/ginkgo"
    . "github.com/onsi/gomega"
    . "github.com/the-gigi/multi-git/pkg/helpers"
    "os"
    "strings"
)
```

It also defines a constant for the base directory and a variable for the list of repos.

```
const baseDir = "/tmp/test-multi-git"

var repoList string
```

The `removeAll()` function is identical to the function from the unit tests and removes the base directory completely. It can be argued it should be moved to the helpers package. The BeforeEach function, which is called before every test, calls `removeAll()` and then rec-creates the base directory from scratch. Therefore, before each test, we start with an empty base directory.

After all the tests finish, the AfterSuite is called once, and the program calls `removeAll()` to clean up the base directory.

```
var _ = Describe("multi-git e2e tests", func() {
    var err error

    removeAll := func() {
        err = os.RemoveAll(baseDir)
        Ω(err).Should(BeNil())
    }

    BeforeEach(func() {
        removeAll()
        err = CreateDir(baseDir, "", false)
        Ω(err).Should(BeNil())
    })

    AfterSuite(removeAll)
```

Check out the `e2e_tests` directory and the files it contains in the application below:

In this lesson, you’ll learn where to put end-to-end tests, and we'll discuss how to build a solid foundation for end-to-end tests, which is very different from unit tests.

Building the Foundation for End to End Tests

Overview

Restructuring multi-git

Testing 1,2,3...

Adding Smart Command-Line Parsing

Adding Advanced Configuration

Adding Bells and Whistles

Summary

Building the Foundation for End to End Tests

Locating end-to-end tests