我正在努力将单元测试集成到我工作的团队的开发过程中,并且有一些怀疑论者.有什么好的方法可以让团队中持怀疑态度的开发人员相信单元测试的价值？在我的具体情况下,我们将添加单元测试,因为我们添加功能或修复了错误.不幸的是,我们的代码库不适合简单的测试.
我想知道哪个单元测试框架真的很熟悉？我知道这可能是一个意见问题,但我想我还是会问.我知道有一天我需要这样做,所以我不妨学习使用它.我知道那里有很多,但哪一个对C#开发有效？
从这个问题我可以看出单元测试是必要的,但我个人并没有使用它.这就是我问这个问题的原因.
我想知道大多数人在什么时候写单元测试.我通常在编写初始代码后编写测试,以确保它的工作方式符合预期.然后我修复了破碎的东西.
我已经非常成功地使用这种方法,但一直想知道是否可能首先转向编写测试会有利吗？
可能重复:
单元测试值得付出努力吗？
我知道一般来说单元测试的目的是什么,但我发现了一些困扰我的事情.
1)测试早期错误发现的目的.因此,在后来的一些迭代中,如果我对代码进行一些更改,自动化测试必须让我惊慌失措并告诉我,我已经搞砸了很久以前被遗忘的软件.
但是,假设我有A类并说它与其他类的实例交互,称之为B类.
当为A类编写单元测试时,他必须模拟B类.因此,在某些将来,如果在B类中做出一些改变,并且导致一些错误,它们将只反映在B类的单元测试中,而不是A的('因为A的测试不使用真正的B类,但它是固定输入和输出的模拟).所以,我看不出单元测试怎么能及早通知一些人不知道的错误？我知道课堂上可能存在的错误,我正在改变,我不需要对它进行单元测试,我需要测试来警告我的变化后果,这些错误会导致一些"被遗忘"的类中的错误,而这不是单元测试可能.还是我错了？
2)当编写模拟和调用方法,输入和返回值的正确期望时,必须知道将如何实现测试类.我认为这与测试驱动的开发相矛盾.在TDD中,首先编写测试,然后由它们驱动,编写代码.但除非我编写必须进行测试的代码,否则我无法写出正确的期望(以及一般的测试).这与TDD相矛盾,对吧？
如果我使用真实对象而不是模拟,这两个问题都可以解决.但那不是单元测试,对吗？在单元测试中,测试类必须与系统的其余部分隔离,而不是使用真实类而是模拟.
我确定我错了,但我无法找到.我一直在阅读和阅读,我找不到我理解错误的东西.