引言
这篇文章来自斯坦福大学计算与数学工程所（Institute for Computational & Mathematical Engineering）博士生Guillaume Genthial的博客。主要介绍了如何将工程界里已经得到充分认可的单元测试实践应用到算法建模的领域中，从而保障模型设计的正确性，具有普适参考价值。在翻译本文时，没有完全遵照原文逐字翻译，但尽可能保留了原文比较活泼的表达方式和内容结构。
文章中所用示例的代码已上传到Github。
概述
有谁敢说他在编写某些Tensorflow（或者Theano、pyTorch等）的模型时，从未遇见过一些神秘的异常报错信息呢？我十分确信自己不会是唯一那个曾经花费无数个小时，坐在电脑屏幕前调试代码，并试图理解这些错误信息的人。当然，随着我们经历的这种事情多了，再见到类似错误，十有八九都能猜出来是出的什么故障。即使如此，我们还是会有猜错的时候，更何况有时候错误的代码未必会立即导致运行报错，而是很可能从表面上看起来一切风平浪静。
如何确保自己写的模型真的会按照预想方式运行呢？
有时候我们只是在调用某个TensorFlow算子的时候犯了一些微不足道的错误（或者是弄混了一些东西）就足以把一切都搞砸。咋看起来模型运行起来了，但它实际上根本没在做你期望的事情。这些不会直接把程序弄挂的Bug排查起来简直令人抓狂，并且它们出现的概率远比我们认为的高得多。这也是最近发布的Open AI Baselines项目的初衷。Szymon Sidor和John Schulman指出了其中的关键点。
留意那些不会直接破坏程序运行的Bug：我们观察了十个当下流行的强化学习算法的重新实现版本，其中的六个都被社区成员指出了代码上的Bug并得到原作者的确认。包括很小的问题譬如在某些样本上丢失了梯度，或者不正确的卷积参数，也有相当糟糕的问题譬如会导致生成报告的分数比真实运行结果更高的代码。
换句话说，如果我们愿意听听经验丰富的研究员和工程师们的心声，编写测试的驱动力深深的根植于他们的实践里：
- 避开那些微妙的Bug，写出正确的代码（从而获得更高的质量和更好的研究成果）
- 节省掉那些四处找问题时间（大概150％的编程老师都会告诉你这个事实）
指导原则
我们先来简要讨论下做测试的两种选择：
- 使用特定的输入数据通过整条数据链路(pipeline)，检验它的输出。
- 采用一种新的编码策略，先将整体算法分解成许多独立的小函数，然后分别验证这些小块的功能
选择1的做法很常见，只要喂点数据进去，训练一下模型，然后在验证集上得到一个看起来不错的结果，以此判断这个模型的正确性。然而这样是不能真正捕获到那些隐藏Bug的。我们再来看看选择2。
选择2的做法还需要配合一些步骤引导。首先，需要准备一些再寻常不过的测试数据，一种不错的办法是随机生成测试数据，然后分别通过分解后的每个小块函数，并记录实际的输出。其次，要准备一个作为对比的参照物，大多数时候，那些为提升运算速度而高度改良过的模型中的许多局部小块都是可以改用Numpy（或者Tensorflow）以及十分粗暴简陋、毫无优化可言（比如在模型里使用for循环）的逻辑实现出来的。
换句话说，以上步骤可以表达为如下示意代码：
for _ in range(number of random tests):
sample x
assert tensorflow_function(x) == naive_function(x)为啥我要强调选择2呢。由于许多人认为反正我现在的做法也蛮管用，何必听取别人意见，也由于我们总喜欢夸大改变日常习惯的难度（其实就是懒惰）。
让我们从一个简单的例子开始吧！
示例
现在，举一个具体的例子，我们想要批量获取Tensorflow张量中指定坐标位置的值（复杂的下标定位操作在Tensorflow里可不是件愉快的事情。本人也曾发表过类似吐槽，译者注）。为此，我们来在Tensorflow中编写一个函数get_entry，用于批量提取张量值。也就是说，已知：
- 一个维度为
[batch, d1, d2]的张量t - 维度为
[batch]的向量indices_1d - 维度为
[batch]的向量indices_2d
我们要计算出一个维度为[batch]的向量o。
∀i ∈ [0, batch), o[i] = t[i, indices_1d[i], indices_2d[i]]注意这个公式没有包含批量获取的过程，仅仅是表达获取矩阵A中坐标位置为(i, j)的值。
Numpy版本的实现
Numpy实现的版本十分简单直接，我们不必在意它的运行效率：
import numpy as np
def get_entry_np(t, indices_d1, indices_d2, batch_size):
result = np.zeros(batch_size)
for i in range(batch_size):
result[i] = t[i, indices_d1[i], indices_d2[i]]
return resultTensorflow版本的实现
在Tensorflow中实现同样的功能则需要用到gather_nd方法。
import tensorflow as tf
def get_entry_tf(t, indices_d1, indices_d2, batch_size):
indices = tf.stack([tf.range(batch_size), indices_d1, indices_d2], axis=1)
return tf.gather_nd(t, indices)运行测试的代码
要写这个测试，我们会用到Pythong的标准单元测试工具包。首先，将它import进来。
import unittest然后定义一个包含多个测试用例的类。
class Test(unittest.TestCase):
def test_1(self):
# always passes
self.assertEqual(True, True)
def test_2(self):
pass
# etc.
if __name__ == '__main__':
unittest.main()在这个场景下，我们只需要编写一个单元测试用例。使用随机数的办法，采样一定量的数据，然后在被测张量上分别记录通过Numpy和Tensorflow版本函数的计算结果，最后验证它们是相等的！
def test_get_entry(self):
success = True
for _ in range(10):
# sample input
batch_size, d1, d2 = map(int, np.random.randint(low=2, high=100, size=3))
test_input = np.random.random([batch_size, d1, d2])
test_indices_d1 = np.random.randint(low=0, high=d1-1, size=[batch_size])
test_indices_d2 = np.random.randint(low=0, high=d2-1, size=[batch_size])
# evaluate the numpy version
test_result = get_entry_np(test_input, test_indices_d1, test_indices_d2, batch_size)
# evaluate the tensorflow version
with tf.Session() as sess:
tf_input = tf.constant(test_input, dtype=tf.float32)
tf_indices_d1 = tf.constant(test_indices_d1, dtype=tf.int32)
tf_indices_d2 = tf.constant(test_indices_d2, dtype=tf.int32)
tf_result = get_entry_tf(tf_input, tf_indices_d1, tf_indices_d2, batch_size)
tf_result = sess.run(tf_result)
# check that outputs are similar
success = success and np.allclose(test_result, tf_result)
self.assertEqual(success, True)现在我们来执行这个包含测试用例的.py文件。
----------------------------------------
Ran 1 test in 0.887s
OK运行成功！现在可以高兴的宣布，我们使用不太直观的Tensorflow代码实现的功能与Numpy的简易版本效果是一致的，因此（基本上）可以确信如果最终的模型出了问题，一定与这个函数无关。
结论
当我写完测试后，不由得惊讶于编写这样一个测试竟然如此之快（不超过10分钟），与我为了把get_entry函数实现正确所花费的时间相比，这点时间几乎可以忽略不计！多亏这些测试保障，我能够更快地进行迭代开发，对可能的参数和解决方案进行尝试，而不至于过度消耗时间，并更快地获得所需的解决方案！为了进一步进行测试驱动开发，常见的一条建议是在每天离开办公室之前就编写完测试，以便第二天不会在一个错误的结果之上继续开发的其他功能！如果有足够信心相信已完成的功能正确，并且能用一种简单直白的方法证明，就可以在早上集中精力关注真正重要的事情！测试驱动开发（TDD）还有一个我们尚未提及的好处：它鼓励将代码分解为可以进行单元测试的小函数。这样写出来的代码必将更通用，更简短，更可具有重用性！
