Test-driven development (TDD) is a process where test cases are created to validate requirements before functional code is written. The primary goals of TDD are to help specify requirements and design and to produce clean, bug-free code through a short development cycle of writing tests then code to pass those tests. Good unit tests for TDD should run fast, isolate dependencies, clearly define their scope, not require special setup, and clearly indicate their intention. In Golang, the testing package and go test command provide tools for writing and running tests, and go test can measure test coverage.

1. Unit Testing - Golang
Sofian Hadiwijaya
@sofianhw

2. What is TDD?
Test-driven development (TDD)
is a software development
process that relies on the
repetition of a very short
development cycle:
requirements are turned into
very specific test cases, then the
software is improved to pass
the new tests, only. This is
opposed to software
development that allows
software to be added that is not
proven to meet requirements.

3. Why TDD Needed?
The primary goal of TDD is, it's specification and not
validation. In other words, it’s one way to think through your
requirements or design before your write your functional
code. The goal of TDD is to write clean code that works
without wasting much of the development time. Main
benefits are :
• Easy to understand the specifications
• Takes much less time for debugging
• Coder can prove that the code meets the requirements
• Shorter development cycles

4. TDD Cycle

5. Characteristics of a Good Unit Test
• It should run fast. If the tests are slow, they will not be run often.
• Separates or mock environmental dependencies such as databases,
file systems, networks etc. These dependencies will slow the test
process, and a failure does not give meaningful feedback about
what the problem actually is.
• The scope should be clear. If the test fails, it's obvious where to look
for the problem. It's important to only test one thing in a single test.
• If the tests require special environmental setup or fail unexpectedly,
then they are not good unit tests. Change them for simplicity and
reliability. Tests should run and pass on any machine. The "works on
my box" excuse doesn't work.
• Clearly reveals its intention. Another developer can look at the test
and understand what is expected of the production code.

6. Unit Test in Golang
• Go has a built-in testing command called go test and a package
testing which combine to give a minimal but complete testing
experience.
• The standard tool-chain also includes benchmarking and
statement-based code coverage

7. Good Unit Test
Characteristics of a Golang test function:
• The first and only parameter needs to be t *testing.T
• It begins with the word Test followed by a word or phrase
starting with a capital letter.(usually the method under test i.e.
TestValidateClient)
• Calls t.Error or t.Fail to indicate a failure (I called t.Errorf to
provide more details)t.Log can be used to provide non-failing
debug information
• Must be saved in a file named something_test.go such as:
addition_test.go

8. Writing Test

9. Writing Test

10. Test Table

11. Launching Test
There are two ways to launch tests for a package. These methods
work for unit tests and integration tests alike.
1. Within the same directory as the test:
go test
This picks up any files matching packagename_test.go
2. By fully-qualified package name
go test github.com/sofianhw/golang

12. Cover
The go test tool has built-in code-coverage for statements. To try it
with out example above type in:

13. Demo

14. Thanks !!!
www.sofianhw.com @sofianhw sofian@pinjam.co.id