手把手教你写go单元测试

于 2024-03-31 10:50:55 发布
阅读量1.3k 收藏 18
点赞数 9
分类专栏： go语言 文章标签： golang 单元测试 开发语言
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/vpertj/article/details/137194409
版权

什么是单元测试

​ 在 Go 语言中，单元测试是一种测试方法，用于验证代码的某个独立单元是否按预期功能，它的目的是确保代码的每个组成部分都在独立测试的情况下运行正常。

​ 在我们对项目新增一个新功能时，最好就要养成写单元测试的好习惯，这样可以有助于提高我们代码的质量、可维护性和可靠性。

​ 在 Go 中，单元测试的约定是使用标准库中的 testing 包。测试文件通常以 _test.go 为后缀，然后我们使用 go test ... 配合一些参数去进行测试，Go 测试工具会自动识别并运行这些文件中那点测试样例。

go test 的两种模式
1. 本地模式：执行当前目录下的所有测试用例

​ go test

2. 列表模式：输入一个或多个目录，执行这些目录下的测试用例

​ go test xx/xx

怎么写单元测试

​ 首先，要写单元测试，那么肯定需要一个功能函数。这里我们借用一下之前文章内存缓存系统中使用到的一个功能函数 ParseSize ，它的功能是将用户的输入内存大小，转换为字节数和对应的字符串表示形式，其中还会涉及到一些输入不合法的处理，

​ 本文讲的是如何写单元测试，这里 ParseSize 的源码就直接给大家了，如下：

package util

import (
    "regexp"
    "strconv"
    "strings"
    "time"
)

const (
    B = 1 << (iota * 10)
    KB
    MB
    GB
    TB
    PB
)

const defaultNum = 100

func ParseSize(size string) (int64, string) {
    time.Sleep(time.Nanosecond * 500)

    re, _ := regexp.Compile("[0-9]+")
    unit := string(re.ReplaceAll([]byte(size), []byte("")))
    num, _ := strconv.ParseInt(strings.Replace(size, unit, "", 1), 10, 64)
    unit = strings.ToUpper(unit)

    var byteNum int64 = 0
    switch unit {
    case "B":
        byteNum = num
    case "KB":
        byteNum = num * KB
    case "MB":
        byteNum = num * MB
    case "GB":
        byteNum = num * GB
    case "TB":
        byteNum = num * TB
    case "PB":
        byteNum = num * PB
    default:
        num = 0
    }

    if num == 0 {
        num = 100
        byteNum = num * MB
        unit = "MB"
    }

    sizeStr := strconv.FormatInt(num, 10) + unit
    return byteNum, sizeStr
}

 在项目根目录下创建 util 目录，然后创建 util.go 文件，将上面的代码粘贴进去就行了。

​ 强调一点，上面的 ParseSize 函数的开头，我加了一个睡眠函数，是因为我们的 ParseSize 函数的处理逻辑比较简单，怕执行太快，进行测试时显示时间为 0 ，所以加了个睡眠延迟一点时间，模拟一些比较耗时功能函数。

准备工作

​ 同样，我们先在 util 包下创建 util_test.go 文件。在写单元测试的时候，我们通常有两种方法，一种是在测试函数里面构建匿名结构体来组织数据，另一种就是在提前构建数据。前者就是将构建数据的逻辑写在测试函数里，这里不多做介绍，我们要着重讲的是第二种。

​ 为了方便，我们先定义一个结构体，并将其实例化，用于存放我们的数据：

// 所有的测试用例放在这里头
var commTestData []commStruct

type commStruct struct {
    Group         string // 所属类别
    SizeStr       string // 输入大小
    ExpectSize    int64  // 预期输出大小
    ExpectSizeStr string // 预期输出大小字符串类型
}
  • Group：这个是用于子测试时分类的依据，关于子测试后面会提到，这里先不理会。
  • SizeStr：是对应于我们的 ParseSize 功能函数的输入
  • ExpectSize、ExpectSizeStr：对应于我们的 ParseSize 功能函数的输出

​ 在单元测试中，也有一个 func TestMain(m *testing.M)入口函数，功能和用法于平时我们使用的 main 类似。我们可以在这里面为单元测试做一些准备工作，但需要注意的是：如果我们没有写 TestMain 函数，那么测试工具会直接调用我们的测试函数，但如果我们写了 TestMain 函数，就需要在 TestMain 中通过 m.Run() 显示地调用测试用例：

// 测试用例的入口函数：可以为测试做一些准备工作
func TestMain(m *testing.M) {
    initCommonData()
    m.Run() // 执行测试用例
}

func initCommonData() {
    commTestData = []commStruct{
        {"B", "1b", B, "1B"},
        {"B", "100b", 100 * B, "100B"},
        {"KB", "1kb", KB, "1KB"},
        {"KB", "100KB", 100 * KB, "100KB"},
        {"MB", "1Mb", MB, "1MB"},
        {"GB", "10Gb", 10 * GB, "10GB"},
        {"TB", "1tb", TB, "1TB"},
        {"PB", "10PB", 10 * PB, "10PB"},
        {"unknown", "1G", 100 * MB, "100MB"},
    }
}

上面我们通过 TestMain 函数，提前构建好了测试所需要的数据，避免在不同的测试函数中重复构建测试用例。

功能测试

​ 功能测试是一种验证代码是否按照规范和需求进行工作的测试，它关注于测试单个函数或方法的功能是否正确，以确保其符合预期的行为。

​ 根据它的定义，我们就大概知道该怎么写我们的功能测试了。首先功能测试的函数签名是这样的 func TestFunctionName(t *testing.T)。我们直接在函数里面写逻辑即可，因为有很多组测试样例，所以我们肯定要用 for 循环将所有的样例拿出来，然后一一进行验证，验证的过程就是将该样例的输入拿出来执行一遍功能函数，然后将结果与我们的样例预期结果进行比对即可，如下：

// 功能测试
func TestParseSize(t *testing.T) {
    testData := commTestData
    for _, data := range testData {
        size, sizeStr := ParseSize(data.SizeStr)
        if size != data.ExpectSize || sizeStr != data.ExpectSizeStr {
            t.Errorf("测试结果不符合预期：%+v", data)
        }
    }
}

​ 这样我们就写好了一个具备基本功能的功能测试代码了。我们可以通过命令 go test -v 去执行，输出如下：

$  go test -v
=== RUN   TestParseSize
--- PASS: TestParseSize (0.14s)
PASS
ok      main/util       0.178s

​ 我们一起来看看这个输出：

  1. === RUN TestParseSize：表示正在运行名为 TestParseSize 的测试函数。
  2. --- PASS: TestParseSize (0.14s)：表示测试函数 TestParseSize 成功通过，用时 0.14 秒。PASS 表示测试通过，FAIL 则表示测试失败。
  3. PASS：表示整个测试过程中没有发现错误，所有的测试函数都成功通过。
  4. ok main/util 0.178s：表示测试包 main/util 成功通过，总用时为 0.178 秒。

​ 下面我们再来看看功能测试的子测试。

​ 功能测试的子测试，又可以叫做并发测试，我们可以利用它来加快测试的效率。我们下面以测试样例中的单位，即 group 字段来将测试样例分个组：

testData := make(map[string][]commStruct)
for _, item := range commTestData {
    group := item.Group
    _, ok := testData[group]
    if !ok {
        testData[group] = make([]commStruct, 0)
    }
    testData[group] = append(testData[group], item)
}

​ 有了数据，其实我们的子测试，就相当于对不同组别分别去进行测试。

​ 所以首先要用一个 for 循环拿出不同组别的数据，去分别运行，然后在每个组别运行时，去拿出对应组别的数据去做验证即可，代码如下：

func TestParseSizeSub(t *testing.T) {
    if testing.Short() {
        t.Skip("跳过测试用例 TestParseSizeSub")
    }

    // 按照 group 分个组
    testData := make(map[string][]commStruct)
    for _, item := range commTestData {
        group := item.Group
        _, ok := testData[group]
        if !ok {
            testData[group] = make([]commStruct, 0)
        }
        testData[group] = append(testData[group], item)
    }

    // 分组去测试 测试数据
    for k, _ := range testData {
        t.Run(k, func(t *testing.T) {
            // 下面的子测试样例就会去并行执行：通过睡眠可以看出效果
            t.Parallel()
            for _, data := range testData[k] {
                size, sizeStr := ParseSize(data.SizeStr)
                if size != data.ExpectSize || sizeStr != data.ExpectSizeStr {
                    t.Errorf("测试结果不符合预期：%+v", data)
                }
            }
        })
    }
}

​ 细心的小伙伴一定看到了上面有两个点是我们没讲的：

  1. if testing.Short() 这个是做什么的呢？还记得我们上面介绍参数的时候说过吗，这个参数是用来避免一些不必要的测试的，所以如果我们的测试不需要，就可以使用 short 参数跳过这个子测试。
  2. t.Parallel() 这个就是我们子测试并行测试的关键了，只有加了这行代码，我们的子测试才能进行并行测试。

​ 下面带大家看看t.Parallel() 是不是真的有效果，我们在子测试代码中加入一个睡眠时间，先把 t.Parallel() 注释掉：

for k, _ := range testData {
    t.Run(k, func(t *testing.T) {
        //t.Parallel()
        for _, data := range testData[k] {
            time.Sleep(time.Second)
            size, sizeStr := ParseSize(data.SizeStr)
            if size != data.ExpectSize || sizeStr != data.ExpectSizeStr {
                t.Errorf("测试结果不符合预期：%+v", data)
            }
        }
    })
}

​ 然后执行命令 go test -v，可以观察到子测试的样例每隔一秒才执行一次，最终耗时 9.367 秒。

$  go test -v
=== RUN   TestParseSize
--- PASS: TestParseSize (0.10s)
=== RUN   TestParseSizeSub
=== RUN   TestParseSizeSub/KB
=== RUN   TestParseSizeSub/MB
=== RUN   TestParseSizeSub/GB
=== RUN   TestParseSizeSub/TB
=== RUN   TestParseSizeSub/PB
=== RUN   TestParseSizeSub/unknown
=== RUN   TestParseSizeSub/B
--- PASS: TestParseSizeSub (9.22s)            
    --- PASS: TestParseSizeSub/KB (2.05s)     
    --- PASS: TestParseSizeSub/MB (1.02s)     
    --- PASS: TestParseSizeSub/GB (1.02s)     
    --- PASS: TestParseSizeSub/TB (1.03s)     
    --- PASS: TestParseSizeSub/PB (1.03s)     
    --- PASS: TestParseSizeSub/unknown (1.03s)
    --- PASS: TestParseSizeSub/B (2.04s)      
PASS
ok      main/util       9.367s

​ 我们再把 t.Parallel() 的注释去掉，再执行 go test -v 观察一下：

$  go test -v
=== RUN   TestParseSize
--- PASS: TestParseSize (0.14s)
=== RUN   TestParseSizeSub
=== RUN   TestParseSizeSub/unknown
=== PAUSE TestParseSizeSub/unknown
=== RUN   TestParseSizeSub/B
=== PAUSE TestParseSizeSub/B
=== RUN   TestParseSizeSub/KB
=== PAUSE TestParseSizeSub/KB
=== RUN   TestParseSizeSub/MB
=== PAUSE TestParseSizeSub/MB
=== RUN   TestParseSizeSub/GB
=== PAUSE TestParseSizeSub/GB
=== RUN   TestParseSizeSub/TB
=== PAUSE TestParseSizeSub/TB
=== RUN   TestParseSizeSub/PB
=== PAUSE TestParseSizeSub/PB
=== CONT  TestParseSizeSub/unknown
=== CONT  TestParseSizeSub/GB
=== CONT  TestParseSizeSub/PB
=== CONT  TestParseSizeSub/TB
=== CONT  TestParseSizeSub/KB
=== CONT  TestParseSizeSub/MB
=== CONT  TestParseSizeSub/B
--- PASS: TestParseSizeSub (0.00s)
    --- PASS: TestParseSizeSub/TB (1.03s)
    --- PASS: TestParseSizeSub/B (1.03s)
    --- PASS: TestParseSizeSub/MB (1.03s)
    --- PASS: TestParseSizeSub/PB (1.03s)
    --- PASS: TestParseSizeSub/KB (1.03s)
    --- PASS: TestParseSizeSub/unknown (1.03s)
    --- PASS: TestParseSizeSub/GB (1.03s)
PASS
ok      main/util       1.210s

​ 会发现子测试几乎是同时打印出来的信息，最终耗时 1.120s，这就验证了 t.Parallel() 的作用，也同时验证了功能测试的子测试的作用。

模糊测试

​ 模糊测试是一种随机生成输入数据并将其提供给函数或程序的测试方法，它可以帮助发现潜在的边界情况和异常输入，以检测代码的鲁棒性。

​ 也就是说，模式测试本质上也是功能测试，只不过模糊测试的输入不再是我们提前构建好的数据，而是测试工具根据我们传入的参数类型去帮我们构建各种输入，以此来检测我们的功能函数在这种随机构造的输入情况下，是否还能照常工作。模糊测试的函数签名是func FuzzFunctionName(f *testing.F) {}，如下：

func FuzzParseSize(f *testing.F) {
    // 也就是说，模糊测试，本质上也是一个功能测试。
    // 只是输入的内容不再是 data，而是所谓的 a
    f.Fuzz(func(t *testing.T, a string) {
        size, sizeStr := ParseSize(a)
        if size == 0 || sizeStr == "" {
            t.Errorf("输入异常，导致 parsesize 没拿到正确结果")
        }
    })
}

​ 然后我们可以通过 go test -fuzz FuzzParseSize 命令开启模糊测试，输出如下：

go test -fuzz FuzzParseSize
warning: starting with empty corpus
fuzz: elapsed: 0s, execs: 0 (0/sec), new interesting: 0 (total: 0)
fuzz: elapsed: 3s, execs: 614 (205/sec), new interesting: 7 (total: 7)
fuzz: elapsed: 6s, execs: 4210 (1194/sec), new interesting: 22 (total: 22)
fuzz: elapsed: 9s, execs: 5579 (456/sec), new interesting: 26 (total: 26)
fuzz: elapsed: 12s, execs: 9227 (1221/sec), new interesting: 35 (total: 35)
fuzz: elapsed: 15s, execs: 14480 (1744/sec), new interesting: 44 (total: 44)
fuzz: elapsed: 18s, execs: 16198 (572/sec), new interesting: 49 (total: 49)
......
  1. warning: starting with empty corpus：这是一个警告，表示开始时模糊测试的语料库（corpus）是空的。语料库是用来保存历史模式测试时，出现错误的样例。
  2. elapsed：经过的时间
  3. execs：执行的测试次数（平均每秒执行多少次）
  4. new interesting：新增的随机测试输入个数
  5. total：本次测试的的输入样例个数

​ 运行模糊测试，你会发现根本不会停，只能主动去停止，这也是为什么模糊测试只能同时测试的原因。

​ 还有就是上面提到的预料库，在运行模糊测试时，如果出现了预期之外的错误，那就会将这个样例保存到语料库中，并且在之后每次的模糊测试都会去运行这些出错的样例。语料库也是保存在本地的，会在根目录下生成一个对应的文件去存放。

性能测试

​ 最后我们再来看看性能测试，在进行性能测试之前，我们需要先将 ParseSize 函数中的睡眠函数关掉，避免影响我们的性能测试。因为Sleep() 不仅会让程序睡眠，还会做一些其他处理，会对我们的性能测试产生不小的影响。

​ 待会我们也可以做一个测试，然后进行一个对比。

​ 性能测试写起来条条框框会比较多，它的函数签名是这样的 func BenchmarkFunctionName(b *testing.B) {}我们啥也先不管，先来个 for 循环，然后直接调用我们的 ParseSize 函数：

func BenchmarkParseSize(b *testing.B) {
    for i := 0; i < b.N; i++ {
        ParseSize("1MB")
    }
}

​ 这样，一个简易的性能测试就写完了，我们可以用 go test -bench BenchmarkParseSize，这里先不注释 ParseSize 中的睡眠函数，我们看看效果：

go test -bench BenchmarkParseSize
goos: windows
goarch: amd64
pkg: main/util
cpu: AMD Ryzen 7 4800H with Radeon Graphics
BenchmarkParseSize-16                100          15301008 ns/op
BenchmarkParseSizeSub/B-16           100          14830110 ns/op
BenchmarkParseSizeSub/KB-16          100          15324944 ns/op
BenchmarkParseSizeSub/MB-16          100          15445510 ns/op
BenchmarkParseSizeSub/GB-16          100          14851633 ns/op
BenchmarkParseSizeSub/TB-16          100          15136910 ns/op
BenchmarkParseSizeSub/PB-16          100          15281375 ns/op
BenchmarkParseSizeSub/unknown-16                     100          15188822 ns/op
PASS
ok      main/util       22.495s

​ 再将睡眠函数注释掉，运行同样的命令，看看效果：

go test -bench BenchmarkParseSize                                    
goos: windows
goarch: amd64                                       
pkg: main/util                                      
cpu: AMD Ryzen 7 4800H with Radeon Graphics         
BenchmarkParseSize-16             735984              1603 ns/op
BenchmarkParseSizeSub/B-16        704841              1616 ns/op
BenchmarkParseSizeSub/KB-16       750050              1630 ns/op
BenchmarkParseSizeSub/MB-16       748998              1647 ns/op
BenchmarkParseSizeSub/GB-16       635871              1689 ns/op
BenchmarkParseSizeSub/TB-16       769012              1639 ns/op
BenchmarkParseSizeSub/PB-16       748689              1642 ns/op
BenchmarkParseSizeSub/unknown-16                  770593              1620 ns/op
PASS
ok      main/util       19.901s

​ 我们先来解释一下各个参数代表什么：

  1. goos: windows 和 goarch: amd64：表示你的操作系统和体系结构。
  2. pkg: main/util：表示正在测试的 Go 包的路径。
  3. cpu: AMD Ryzen 7 4800H with Radeon Graphics：表示你的 CPU 信息。
  4. BenchmarkParseSize-16 735984 1603 ns/op：表示运行了 735984 次，平均每次耗时 1603 纳秒
  5. PASS：表示所有的性能测试都通过
  6. ok main/util 19.901s：表示整个测试过程消耗了 19.901 秒。

​ 可以很明显的看到，这里两次测试的平均每次迭代耗时差了很多个数量级，但算上我们的睡眠时间 time.Sleep(time.Nanosecond * 500)，也就 500 ns 而已。之所以会这样是因为 time.Sleep 函数的调用对于测试的结果会产生较大的影响，特别是在精度较高的情况，比如我们这里的纳米级别。 time.Sleep 会导致当前 goroutine 挂起，等待指定的时间再继续执行。在测试中，这样的挂起会导致每次迭代的耗时相对较大，从而影响性能测试的结果。

​ 可能会有人好奇，为什么平均时长差了很多，但是总耗时却差不多。因为在 Go 语言的性能测试中，每个子测试的迭代次数数由测试框架自动决定的，它会根据自己执行时间的变化动态调整迭代次数，以保证测试结果的稳定性和可靠性。我们也可以自己使用 -benchtime t 参数来配置自己想要的运行次数和时间。

​ 下面我们再来看看说说性能测试的子测试。

​ 性能测试的子测试，其实没有啥明确的使用场景，我们下面所举的例子，也只是为了写性能测试子测试而写子测试，能够使用的场景也就是需要分组归类去测试的数据，比如 B、KB、MB 等相同单位的一组去测试。

​ 这样做的好处是啥？有人肯定会觉得，可以像功能测试那样做并行测试。

​ 答案是否定的，性能测试的子测试没有并行机制。我个人觉得这样的好处就是，可以指定只执行对应分组的测试用例，比如我们只需要对某一个单位的大小进行特殊处理，就可以只去执行对应分组的测试用例了。

​ 然后我们来看看怎么写，同样的，需要先对我们的测试样例进行分组，然后在用 for 对不同组别的测试样例分别去运行性能测试函数：

func BenchmarkParseSizeSub(b *testing.B) {
    testData := make(map[string][]commStruct)
    for _, item := range commTestData {
        group := item.Group
        _, ok := testData[group]
        if !ok {
            testData[group] = make([]commStruct, 0)
        }
        testData[group] = append(testData[group], item)
    }

    for k, _ := range testData {
        b.Run(k, func(b *testing.B) {
            for i := 0; i < b.N; i++ {
                ParseSize(testData[k][0].SizeStr)
            }
        })
    }
}

​ 上面代码需要知道的一点，就是在每次运行 b.Run() 的时候，for 循环里的测试次数是测试工具自动决定的，我们只需要调用就可以了。

​ 上面就差不多是性能测试的基本写法了，只不过在一些情况下，比如我们在每次测试时需要去进行一下其他的数据准备，如果不进行一些处理，这些准备数据的时间就可能会导致我们的性能测试偏差较大：

for k, _ := range testData {
    b.Run(k, func(b *testing.B) {
        // case1
        preBenchmark()
        for i := 0; i < b.N; i++ {
            // case2
            preBenchmark1()
            ParseSize(testData[k][0].SizeStr)
        }
    })
}

func preBenchmark1() {
    time.Sleep(10 * time.Second)
}

func preBenchmark2() {
    time.Sleep(time.Nanosecond * 500)
}

​ 在上述代码中，我们通过 preBenchmark1 和 preBenchmark2 函数模拟了准备数据等其他操作的耗时，这里就直接告诉大家解决的方法了：

  • 对于 case1：可以在数据准备完成后，使用b.ResetTimer() 重置计时器
  • 对于case2：可以在准备数据前使用 b.StopTimer() 将计时器暂停，然后在准备好数据后，重新启动计时器 b.StartTimer()，这样就可以减小误差。
for k, _ := range testData {
    b.Run(k, func(b *testing.B) {
        // for 循环外，可以通过 b.ResetTimer() 来重置
        preBenchmark1()
        b.ResetTimer()
        for i := 0; i < b.N; i++ {
            // for 循环内，可以通过 b.StopTimer() 和 b.StartTimer() 配合使用，来跳过我们不想统计的耗时操作。迫不得已不要使用，测试速度慢
            b.StopTimer()
            preBenchmark2()
            b.StartTimer()
            ParseSize(testData[k][0].SizeStr)
        }
    })
}

​ 这里强调一点，上面的解决办法也只能减缓误差，并不能真正避免误差。并且如果你要测试上述代码的话，记得加上-benchtime 限制一下执行次数，否则会等很久。

如何在 Go 中写出高效的单元测试
Salted fish in hand, I have the world.
01-14 596
文章目录单测的重要性Go 单测基础知识基本规则go test 使用表格测试HTTP 测试其它测试框架TestifyGoConveyGinkGo其它 Mock 库GoMockHTTPMockSQLMock与 Docker 集成总结参考 单测的重要性 方便 debugging 方便代码重构 提升代码质量 使整个过程敏捷 Go 单测基础知识 基本规则 通常我们的单元测试代码都放在以 _test.go 结尾的文件中，该文件一般和目标代码放在同一个 package 中。 测试的方法以为 Test 开头，并且拥
手把手教你java程序调试
xingshangyy的博客
09-10 1107
编辑器： intelliJIDEA 版本：java1.8 调试快捷键： F8：下一行 F9：下一个断点 F7：进入方法 接下来调试开始 第一步：构建方法nowFormatDate 第二步：构建单元测试方法testString4Date，构建假数据 调用调试方法nowFormatDate 第三步：构建单元测试testString4Date 在代码行号之后空白处点击左键，出现红色圆点标识断点成功 第四步：在nowFormatDate方法中增加断点 第五步：鼠标放置在testString4Date方法名上
100. Go单测系列0---单元测试基础
最新发布
YouMing_Li的博客
03-11 1470
本文介绍了Go语言单元测试的基本用法，通过为Split函数编写单元测试的真实案例，模拟了日常开发过程中的场景，一步一步详细介绍了表格驱动测试、回归测试和常用的断言工具的使用。在下一篇中，我们将更进一步，详细介绍如何使用httptest和gock工具进行网络测试。
Go 语言编写单元测试
weixin_33909059的博客
01-08 3456
吾尝终日而思矣，不如须臾之所学也；吾尝跂而望矣，不如登高之博见也。登高而招，臂非加长也，而见者远；顺风而呼，声非加疾也，而闻者彰。假舆马者，非利足也，而致千里；假舟楫者，非能水也，而绝江河。君子生非异也，善假于物也。 -- 荀况 《劝学》 Go 语言对于单元测试是很重视的，且不说其他的作者的背景啊，开源库啊，第三方的支持之类的，有两点让我对 Go 语言关于单元测试的重视程度的有信心的点...
如何高效编写Go单元测试（一）
ruanrunxue的博客
12-23 541
前言 单元测试是用来对一个模块、一个函数或者一个类来进行正确性检验的测试工作。我们根据它来检验代码的行为是否和预期的一样，如果单元测试不通过，要么代码有bug，要么测试条件输入不正确，总之，需要修复使单元测试能够通过。单元测试一个最大的好处，就是确保一个程序模块的行为符合我们设计的预期，在将来对代码进行修改/重构时，还能最大限度地保证代码的行为仍然正确。 Go对单元测试的支持已经相当友好了，原生的go test标准库就是专门用来进行单元测试的编写的。使用go test编写单元测试时需要遵循一些约定，比如所有
Go语言开发-单元测试怎么写
Charliewolf的博客
04-24 1037
开发环境GoLand，Go版本1.12.1 Go语言，单元测试怎么写 吴军老师讲过： 提高程序质量水平，可以从写单元测试这种可操作的事情做起。 Google为了保证工程师所写程序的质量，鼓励大家多写测试代码。 凡事做记录，这样可以避免狗熊掰棒子。 大部分人过分相信自己的记忆力，以为自己能记住，但实际上很快忘了。 做记录的好处是，在记录过程中，又思考了一遍，进步得会更快。 Google每周会进行...
Go语言基础之单元测试
weixin_30470643的博客
09-13 693
目录 一、go test工具 二、测试函数 三、测试函数的格式 四、测试函数示例 五、测试组 六、子测试 七、测试覆盖率 八、基准测试 九、基准测试函数格式 十、基准测试示例 ...
Go语言XML预处理与后处理：【专家手把手】教你提升效率
[Go语言XML预处理与后处理：【专家手把手】教你提升效率](https://media.geeksforgeeks.org/wp-content/uploads/20220403234211/SAXParserInJava.png) # 1. Go语言与XML简介 ## 1.1 Go语言的特性及其在XML处理中的...
Go net_http包使用宝典：手把手教你构建快速响应的HTTP服务
[Go net_http包使用宝典：手把手教你构建快速响应的HTTP服务](https://organicprogrammer.com/images/golang-http1-1-client-flow.png) # 1. Go net_http包基础介绍 Go语言的标准库中的`net/http`包，为开发者提供...
手把手教你配置与使用phpunit
此外，还展示了简单的PhpUnit单元测试用例的编写方法。" 在进行PHP单元测试时，phpunit是一个非常重要的工具，它是一个用于PHP的单元测试框架，可以帮助开发者验证代码的正确性。以下是对标题和描述中涉及的知识点...
Go语言编写单元测试用例
m0_70556273的博客
10-26 575
18 {"case 1", args{6, 0}, 0, true},//注意第二个用例是会返回error的，因为除数不能为0，所以此处wantErr为true。等待被测试的文件 division.go 如下，需要在同一个包里写一个测试文件命名为mydivision_test.go。结果为division.go生成了division_test.go文件如下，生成文件的默认前缀为对应的原文件名。不过，包外测试源码文件存在一个弊端，那就是在它们的测试函数中无法测试被测源码文件中的。
go 语言怎么写test测试
热门推荐
code_segment的博客
08-23 1万+
Go怎么写test测试用例开发程序其中很重要的一点是测试，我们如何保证代码的质量，如何保证每个函数是可运行，运行结果是正确的，又如何保证写出来的代码性能是好的，我们知道单元测试的重点在于发现程序设计或实现的逻辑错误，使问题及早暴露，便于问题的定位解决，而性能测试的重点在于发现程序设计上的一些问题，让线上的程序能够在高并发的情况下还能保持稳定。本小节将带着这一连串的问题来讲解Go语言中如何来实现单元测
go -- 单元测试
m0_67460902的博客
08-17 443
go -- 单元测试的特点及其操作
Go语言单元测试
YIYIYI
06-28 2193
Go语言单元测试
GO单元测试
Enzo
03-19 4350
优雅的 Golang 单元测试 编写测试友好的代码 假设我们需要测试一个 TCP 端口的响应是否符合预期，我们编写了这样的一个函数: package example import ( "fmt" "io/ioutil" "net" "strings" ) // GatherTCP : connect and check response func G...
go语言中的单元测试编写
chongyi0058的博客
07-17 126
测试文件 my_test.go 的文件名后缀必须为 _test，文件名前半部分可随意取。 测试函数 Test0001,Test0002等，函数名必须以 Test 前缀，函数名后半部分可随意取，参数必须为 (test *testing.T)。 package main im...
在Gogland里对GO程序进行单元测试！
weixin_30885111的博客
02-10 569
单元测试在程序开发中具有很重要的作用！ 1，可以保证程序代码的健壮，能够最小范围测试程序代码，从而保证程序的正确性！ 2，可以通过单元测试代码快速了解当前的程序。 我在先前的几个软件公司工作时候，都对程序代码进行单元测试，一般来说经过单元测试的程序质量都很好！！现在我使用Gogland来学习GO语言，同时也想用它来开发GO语言程序，那么如何在在Gogland里编写GO程序的单元测试呢？ 一...
Go的单元测试
hmx224_2014的专栏
01-26 847
开发项目过程中，少不了单元测试；下面我们认识下单元测试：Go 语言测试框架可以让我们很容易地进行单元测试，但是需要遵循五点规则。
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

道长来吃糖

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值