我对这个感兴趣是因为孩子在做usaco。在training的时候做题提交以后会告诉哪个 test case 没通过，再根据这个修改程序。但是在考试的时候就只告诉你一共跑了几个通过了几个，不告诉具体faled test case是啥。孩子得自己想什么情况下会失败。因 为有时间限制，能想全不是很容易。这种能力应该怎么培养啊？
学会用property based testing, 不用自己想，机器自动产生。因为人想得再全面，也没有机器枚举全面。特别是处理数据的程序，很适合property based testing，各种边角cases，靠人想是远远不够的。我老的开源库很少有人file bug，就是因为我大量使 用property based testing。
【 在 StarVenus (参商*极品磨工~人不知而不愠) 的大作中提到: 】 : 是不是应该另开一个话题呀：大家觉得不给test case合理吗？王垠倒是强烈反对。 : 我对这个感兴趣是因为孩子在做usaco。在training的时候做题提交以后会告诉哪个 : test case 没通过，再根据这个修改程序。但是在考试的时候就只告诉你一共跑了几个 : 通过了几个，不告诉具体faled test case是啥。孩子得自己想什么情况下会失败。因 : 为有时间限制，能想全不是很容易。这种能力应该怎么培养啊？
是不是应该另开一个话题呀：大家觉得不给test case合理吗？王垠倒是强烈反对。
我对这个感兴趣是因为孩子在做usaco。在training的时候做题提交以后会告诉哪个
test case 没通过，再根据这个修改程序。但是在考试的时候就只告诉你一共跑了几个通过了几个，不告诉具体faled test case是啥。孩子得自己想什么情况下会失败。因
为有时间限制，能想全不是很容易。这种能力应该怎么培养啊？
【 在 helpme (名虚胖字满肥) 的大作中提到: 】
: 工作多年以来，我深刻体会到一个现象，那就是做过“编译器”工作的人，哪怕只做了
: 点皮毛，都容易产生高人一等的心理，以至于在与人合作中出现各种问题。由于他们往
: 往也存在偏执心理和理想主义，所以在恶化人际关系的同时，也可能设计出非常不合理
: 的软件构架，浪费大量的人力物力。
: 我曾经提到的DSL例子，就是这样的两个人。他们都自称做过编译器，成天在我面前高
: 谈阔论，甚至在最基础的概念上班门弄斧，显示出一副“教育”其他人的姿态。其实他
: 们只有一个人做parser，还不算是真正的编译器工作，却总显示出高深莫测的模样。哲
: 人一样捋捋胡子，摇摇脑袋，慢条斯理，嗯……另外一个完全就是外行，只是知道一些
: 术语，成天挂在嘴边。每次他一开口，我都发现这个人并不知道他自己在说什么，却仍
: 然洋洋得意的样子。
: ...................
你那个题目来看看？
【 在 StarVenus (参商*极品磨工~人不知而不愠) 的大作中提到: 】
: 是不是应该另开一个话题呀：大家觉得不给test case合理吗？王垠倒是强烈反对。
: 我对这个感兴趣是因为孩子在做usaco。在training的时候做题提交以后会告诉哪个
: test case 没通过，再根据这个修改程序。但是在考试的时候就只告诉你一共跑了几个
: 通过了几个，不告诉具体faled test case是啥。孩子得自己想什么情况下会失败。因
: 为有时间限制，能想全不是很容易。这种能力应该怎么培养啊？
正式的ACM训练应该会cover这方面
学会用property based testing, 不用自己想，机器自动产生。因为人想得再全面，也没有机器枚举全面。特别是处理数据的程序，很适合property based testing，各种边角cases，靠人想是远远不够的。我老的开源库很少有人file bug，就是因为我大量使
用property based testing。
【 在 StarVenus (参商*极品磨工~人不知而不愠) 的大作中提到: 】
: 是不是应该另开一个话题呀：大家觉得不给test case合理吗？王垠倒是强烈反对。
: 我对这个感兴趣是因为孩子在做usaco。在training的时候做题提交以后会告诉哪个
: test case 没通过，再根据这个修改程序。但是在考试的时候就只告诉你一共跑了几个
: 通过了几个，不告诉具体faled test case是啥。孩子得自己想什么情况下会失败。因
: 为有时间限制，能想全不是很容易。这种能力应该怎么培养啊？