In this episode of Testing All The Things we continues to use Test Driven Development (TDD) to drive out the implementation the simple HTTP REST(ish) API in Go using Gorilla Mux.
The second feature we add is a new endpoint to GET the book by ISBN of the Microservice. Starting with an End to End Test write using Testify and Go HTTP Client to design out how consumers of the API will interact with the /book/{isbn} endpoint.
The code produced during this episode can be found on GitHub
In this episode of Testing All The Things we start to use Test Driven Development (TDD) to drive out the implementation the simple HTTP REST(ish) API in Go using Gorilla Mux.
The first feature we add is a new endpoint to GET the health of the Microservice. Starting with an End to End Test write using Testify and Go HTTP Client to design out how consumers of the API will interact with the /healthcheck endpoint.
The code produced during this episode can be found on GitHub
In this episode of Testing All The Things we refactor the test code we created in episodes 027 – 030. Replacing the hand coded test doubles with ones we create using the Go mocking framework in Testify.
The code produced during this episode can be found on GitHub
This episode of Testing All The Things we finish a series where we look at different forms of Test Doubles. We will look at a different type of Test Double in each of the videos. We will implement our own test doubles, we will not use a mocking framework.
We use Test Doubles to replace the dependencies a class uses in production so we have complete control over its dependencies enabling us to isolate the code under test from the implementation of its dependencies.
In the video we look at the Fake type of Test Double.
The code produced during the Test Doubles episodes can be found on GitHub
This episode of Testing All The Things we continue a series where we look at different forms of Test Doubles. We will look at a different type of Test Double in each of the videos. We will implement our own test doubles, we will not use a mocking framework.
We use Test Doubles to replace the dependencies a class uses in production so we have complete control over its dependencies enabling us to isolate the code under test from the implementation of its dependencies.
In the video we look at the Mock type of Test Double.
The code produced during the Test Doubles episodes can be found on GitHub
This episode of Testing All The Things we continue a series where we look at different forms of Test Doubles. We will look at a different type of Test Double in each of the videos. We will implement our own test doubles, we will not use a mocking framework.
We use Test Doubles to replace the dependencies a class uses in production so we have complete control over its dependencies enabling us to isolate the code under test from the implementation of its dependencies.
In the video we look at the Spy type of Test Double.
The code produced during the Test Doubles episodes can be found on GitHub
In episode 13 of Testing All The Things We implement a Set (Abstract Data Type) in Go
we look at Ginkgo a BDD spec framework and assertion/matching library Gomega.
You can find the code created during this video in this GitHub repository.
In episode 8 of Testing All The Thing we look at TDD in Go. In this video we only use the testing features made available in core language.
You can find all the Test Double code in this GitHub repository
I was recently discussing whether or not you should directly test the functionality of private methods in a Go project. The other person reasoned for testing public and private functions to ensure 100% test coverage.
Testing private functions in Go is very simple. To do this you put your implementation and tests in the same package. The private functions are available in the test file as they are in the implementation file.
However just because you do not write tests that directly access the private functions, this does not mean you cannot achieve 100% code coverage. In fact if you follow Test Driven Development (TDD) most private functions will only be created during refactoring.
I prefer to only test public functions.
Lets go through a slightly contrived example.
We are going to implement a number package with two functions. One will add one integer to another. The second function will take one integer away from another. Both functions will return the result of the sum as the string representation of the number. i.e. result is 4, the value returned “four”.
We will only return a string for numbers between 0 and 10. If the number is out side of that range we will return “Cannot convert # to a string”.
First we implement the functionality of the Add function. Testing and implementing for one simple addition with a result within our range and one addition with a result outside our range.
package number_test
import (
"testing"
"github.com/braddle/blog-testingPrivateFunctions/number"
)
func TestTwoAddTwoReturnsStringFour(t *testing.T) {
act := number.Add(2, 2)
exp := "four"
assertEquals(t, exp, act)
}
func TestSixAndFiveReturnsNumberNotConvertableString(t *testing.T) {
act := number.Add(6, 5)
exp := "Cannot convert 11 to a string"
assertEquals(t, exp, act)
}
func assertEquals(t *testing.T, exp, act string) {
if act != exp {
t.Error("Actual value did not match Expected value")
t.Logf("Expected: %s", exp)
t.Logf("Actual: %s", act)
}
}
package number
import "fmt"
// Add function add together the numbers given and returns the result as a
// string
func Add(a, b int) string {
num := a + b
switch num {
case 4:
return "four"
default:
return fmt.Sprintf("Cannot convert %v to a string", num)
}
}
$ go test -cover -v === RUN TestTwoAddTwoReturnsStringFour --- PASS: TestTwoAddTwoReturnsStringFour (0.00s) === RUN TestSixAndFiveReturnsNumberNotConvertableString --- PASS: TestSixAndFiveReturnsNumberNotConvertableString (0.00s) PASS coverage: 50.0% of statements ok github.com/braddle/blog-testingPrivateFunctions/number 0.001s
So far everything looks good. The tests are all passing and we have 100% test coverage.
Now we implement the functionality of the Minus function. Testing and implementing for one simple subtraction with a result within our range and one subtraction with a result outside our range.
package number_test
import (
"testing"
"github.com/braddle/blog-testingPrivateFunctions/number"
)
// Removed Add Test for Brevity.
func TestSixMinusThreeReturnsStringThree(t *testing.T) {
act := number.Minus(6, 3)
exp := "three"
assertEquals(t, exp, act)
}
func TestThreeMinusSixReturnsNumberNotConvertableString(t *testing.T) {
act := number.Minus(3, 6)
exp := "Cannot convert -3 to a string"
assertEquals(t, exp, act)
}
func assertEquals(t *testing.T, exp, act string) {
if act != exp {
t.Error("Actual value did not match Expected value")
t.Logf("Expected: %s", exp)
t.Logf("Actual: %s", act)
}
}
package number
import "fmt"
// Removed Add function for brevity.
// Minus function take the value of b from the value of a and return the
// result as a string
func Minus(a, b int) string {
num := a - b
switch num {
case 3:
return "three"
default:
return fmt.Sprintf("Cannot convert %v to a string", num)
}
}
$ go test -cover -v === RUN TestTwoAddTwoReturnsStringFour --- PASS: TestTwoAddTwoReturnsStringFour (0.00s) === RUN TestSixAndFiveReturnsNumberNotConvertableString --- PASS: TestSixAndFiveReturnsNumberNotConvertableString (0.00s) === RUN TestSixMinusThreeReturnsStringThree --- PASS: TestSixMinusThreeReturnsStringThree (0.00s) === RUN TestThreeMinusSixReturnsNumberNotConvertableString --- PASS: TestThreeMinusSixReturnsNumberNotConvertableString (0.00s) PASS coverage: 100.0% of statements ok github.com/braddle/blog-testingPrivateFunctions/number 0.002s
We now have two functions and all the tests are passing with 100% test coverage. So far so good. However we have some duplication, this can be removed with a small refactor.
We already have all the test we need. We just need to move the duplicate code to it own function. There is currently no need for its functionality to be accessed from outside of the number package so we make it a private function.
package number
import "fmt"
// Add function add together the numbers given and returns the result as a
// string
func Add(a, b int) string {
num := a + b
return intToString(num)
}
// Minus function take the value of b from the value of a and return the
// result as a string
func Minus(a, b int) string {
num := a - b
return intToString(num)
}
func intToString(num int) string {
switch num {
case 3:
return "three"
case 4:
return "four"
default:
return fmt.Sprintf("Cannot convert %v to a string", num)
}
}
$ go test -cover -v === RUN TestTwoAddTwoReturnsStringFour --- PASS: TestTwoAddTwoReturnsStringFour (0.00s) === RUN TestSixAndFiveReturnsNumberNotConvertableString --- PASS: TestSixAndFiveReturnsNumberNotConvertableString (0.00s) === RUN TestSixMinusThreeReturnsStringThree --- PASS: TestSixMinusThreeReturnsStringThree (0.00s) === RUN TestThreeMinusSixReturnsNumberNotConvertableString --- PASS: TestThreeMinusSixReturnsNumberNotConvertableString (0.00s) PASS coverage: 100.0% of statements ok github.com/braddle/blog-testingPrivateFunctions/number 0.002s
Now when we run the tests they all pass, so our refactor is good. We still have 100% test coverage without having to add new tests to cover our new private function intToString. The moved functionality is being indirectly tested by the existing tests on our public functions.
The completed implementation that ensure all some that result in a value between 0 and 10 can be be found in this Github repository.