xUnit我应该测试方法内部工作还是只测试结果？
让我们参加这个单元测试。单元测试指南规定，除非我测试对象的状态，否则每个测试只应该有一个断言。在本例中，Muxer.Muxe是FFMPEG的包装器，它生成正确的命令行并执行它。函数返回“成功”并没有告诉我FFMPEG命令行是否为各种场景正确生成，这需要更多的测试。(例如，需要为AAC文件添加一个额外的标记)。
因此，基于单元测试的正确实践，我是否应该包括测试的最后一部分，测试在方法中正在完成的内部工作，或者没有？
[Theory]
[InlineData("video.mkv", "audio.aac", "dest.mp4")]
[InlineData("video.MKV", "audio.AAC", "Dest.MKV")]
[InlineData("video", "audio", "dest")]
public void Muxe_AudioVideo_Success(string videoFile, string audioFile, string destination) {
var Muxer = SetupMuxer();
var Result = Muxer.Muxe(videoFile, audioFile, destination);
Assert.Equal(CompletionStatus.Success, Result);
Assert.Single(factory.Instances);
IProcessManagerFFmpeg Manager = factory.Instances.FirstOrDefault() as IProcessManagerFFmpeg;
Assert.NotNull(Manager);
output.WriteLine(Manager.CommandWithArgs);
Assert.Contains(audioFile, Manager.CommandWithArgs);
Assert.Contains(videoFile, Manager.CommandWithArgs);
}回答 3
Software Engineering用户
发布于 2019-02-10 14:00:43
基于单元测试正确的实践，我是否应该包括测试的最后一部分，测试方法中正在完成的内部工作，或者没有？
简短的回答:是的，在我看来，你在测试什么是好的。
重要的是要理解:单元测试的责任是独立地验证测试主体是否满足自己的后条件。
因此，如果方法的正确行为应该包括副作用，那么验证这些副作用(或它们的代理)应该是测试的一部分。
Software Engineering用户
发布于 2019-02-10 14:44:21
想想你为什么要做单元测试。(还有“因为我老板告诉我的”，或者“因为这本书告诉我的”不算)。
您进行单元测试的原因如下:验证软件的某一部分(“单元”)是否正常工作；当单元因任何原因停止工作时得到警告；获得指向单元故障区域的指针，为您节省一些工作。
当您查看“指南”时，您需要考虑的是，任何单元测试都比没有单元测试好。这个“每个单元测试一个断言”意味着你必须做十个测试，而不是十个断言。这是更多的工作。这就是为什么根本不可能做到的原因。一个有十个断言的测试要比用一个断言做一个测试好，然后用一个断言进行另一个测试，然后因为工作太枯燥而停止。
针对您的特殊问题:您需要检查调用您的函数是否做了它应该做的事情。仅仅检查它是否返回“成功”是毫无意义的。假设一个客户报告了一个失败，你会说“单元测试运行良好，所以问题肯定在其他地方”。现在你走在完全错误的轨道上，你要花很长时间才能解决这个问题。这比根本没有单元测试更糟糕。
Software Engineering用户
发布于 2019-02-11 17:24:27
由于人类语言过载/歧义与框架术语相互作用，“单一断言”的含义可能令人困惑。
据我所知，您的断言是“命令(行)是格式良好的”，或者，如果要查找特定的错误处理，“命令(行)是格式错误的，因为X是格式错误的”。
要评估格式良好的元属性，可能需要一个较小的结果/状态/属性检查的复合语句。对于大多数非功能方法(即OO)来说，这是正常的，而不是例外。
您可以在一个Assert()调用中使用复合布尔逻辑创建一个断言。但是，假设您的验证语句是以合在一起的范式形式，那么从句的顺序断言(可能按可能失败的降序排列)是测试您的“命令(行)是格式良好的”断言的一种直接方式，其额外好处是明确识别验证过程中的哪个子句失败了。
https://softwareengineering.stackexchange.com/questions/386932
复制相似问题
腾讯云开发者
