I often write a function or module to handle some process that takes 3 or 4
steps to complete.
After I am happy with the code I then proceed to write tests for the code,
but find that I am compelled to chop the code into pieces in order to
simplify the test code
-- thereby losing the nice top down readability with which I started.
The influence that test code has on the structure of the application code
is highly undesirable.
Test code should not exert so much influence over how the primary code is
written.
Here is a proposal that could eliminate this influence -- see explanation
for *with* statements at the end.
package main
import (
"bufio"
"fmt"
"os"
"strings"
)
func main() {
fmt.Printf("Hello folks!\n")
result, err := doSomeStuff("filename.txt", "find_these", 10)
if err != nil {
fmt.Printf("doThisStuff did not succeed! %v\n", err)
}
fmt.Printf("result length is: %v\n", len(result))
}
func doSomeStuff(thing1 string, thing2 string, thing3 int) (map[string]int,
error) {
mystep1 with: thing1 // <---------- hide all function parameters except for
thing1
file, err := os.Open(thing1)
if err != nil {
return nil, err
}
defer file.Close()
var lines []string
scanner := bufio.NewScanner(file)
for scanner.Scan() {
lines = append(lines, scanner.Text())
}
err = scanner.Err()
if err != nil {
return nil, err
}
mystep2 with: lines, thing2 // <---------- hide all local variables from
above except for lines and thing2
mymap := make(map[string]int)
for _, line := range lines {
if strings.Contains(line, thing2) {
count := strings.Count(line, thing2)
mymap[line] = count
}
}
mystep3 with: mymap, thing3 // <---------- hide all local variables from
above except for mymap and thing3
for k, v := range mymap {
if v > thing3 {
mymap[k] = 0
}
}
return mymap, nil
}
The labelled *with* statements would allow for a test to be written
specifically for each step of a function.
Each test would begin at the *with* statement, providing the variables and
values required, and end at the next *with* statement or return statement.
Each step of a function could be tested (or not) without having to refactor
the function into testable pieces
which would lose the natural structure of the original code.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/8eb18eb2-69e7-404a-86be-6c7893a9a7c1%40googlegroups.com.
