在Django应用程序API上执行TDD时，我会编写测试，证明在提供适当的约束时，可以实现预期的结果。如何为输入“错误”的情况的无限排列编写测试。
我想到了两件事：
1）我不应该通过对每个输入进行类型检查来破坏python的动态方面，并且
2）我应该测试“有趣的”函数或方法（不是getter和setter），虽然我不确定这是如何适用于API的
答案 0 :(得分：3)
使用TDD，保持理智的一个好方法是编写覆盖所需数量的有效输入的测试，让测试失败，因为还没有代码，编写尽可能少的代码使它们通过，然后重构代码准备生产，同时确保您的测试仍然通过。听起来你已经做到了这一点。
然后，就无效输入测试而言，我怀疑这些选择确实需要是无限的，并且会陷入几种情况，只需几个替代输入/参数就可以很好地测试（例如：对于整数输入，测试传递零，负整数，大量/溢出整数，字符）。
当然，这仍然需要时间来计算和编码（即使你通过循环变量列表并使用不同的输入重复调用相同的测试来自动化它），虽然它绝对值得做，但如果你想更多的是，您可以随时查看类似fuzz testing的内容。
PS。在测试API方面，我将专注于针对API的公开集合/资源创建测试查询（易于使用Django测试客户端进行单元测试），还可以直接对API使用的任何非平凡方法进行单元测试。封面。然后应该通过更高级别的函数隐式地测试getter和setter等。理论上：o）