无效枚举值的单元测试
我有一堆代码，看起来有点像这样：
If mode = DiaryMode.Admin Then
modeObject = DBNull.Value
ElseIf mode = DiaryMode.Academy Then
modeObject = ApplicationSettings.Academy
ElseIf mode = DiaryMode.Scouting Then
modeObject = ApplicationSettings.Scouting
Else
Throw New NotSupportedException()
End If
检查的想法是准备一些值以传递到数据库调用中。
有两个问题，Else值得付出努力吗？ 目的是防止将来枚举的扩展导致代码返回 sqify 结果。
如果代码有效，我希望能够对行为进行单元测试，如果值得测试的话。 我该怎么做呢？
I have a lump of code that looks a bit like this:
If mode = DiaryMode.Admin Then
modeObject = DBNull.Value
ElseIf mode = DiaryMode.Academy Then
modeObject = ApplicationSettings.Academy
ElseIf mode = DiaryMode.Scouting Then
modeObject = ApplicationSettings.Scouting
Else
Throw New NotSupportedException()
End If
The idea of the check is to prep some values for passing into a database call.
There are two questions, is the Else worth the effort? The intention is to prevent future extensions of the enum causing the code to return squify results.
If the code is valid, I'd like to be able to unit test the behaviour, if it's worth having it's worth testing. How might I go about doing that?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您的业务需求声明不接受其他 DiaryMode，那么 else 语句是一个完美的用途，可以防止将来对 DiaryMode 枚举进行扩展。
至于测试，这会变得有点棘手。 我肯定会测试所有有效的状态（管理员、学院和侦察）。 但是，您无法真正将模式设置为不存在的枚举值，这将是引发 NotsupportedException 的唯一方法。 我可能会考虑尝试编写一个测试来验证枚举是否仅包含您期望的枚举。
您可以通过执行以下操作来做到这一点：
然后验证每个名称。
总而言之，您将进行我所描述的 4 项测试。
If your business requirements state that no other DiaryMode is acceptable, then an else statement is a perfectly fine use to prevent future extension on your DiaryMode enum.
As for testing, that gets a little bit trickier. I would test all valid states (Admin, Academy, and Scouting) for sure. However, you can't really set the mode to an enum value that doesn't exist, and that would be the only way to throw the NotsupportedException. I might look into trying to write a test that would verify that the enum only carries the enumerations your expecting.
You could do that by doing something like this:
and then verifying each name.
To sum up, you'd have 4 tests from what I've described.
您宁愿使用用多态性替换条件来重构它。
为这些行编写一个测试用例将证明“if...then...else”语句返回正确的 modeObject，但我不会花太多时间在上面。 不过，这可能并非完全没有意义：如果您计划添加新模式，测试将确保它们将按预期进行处理，特别是如果会有一些剪切和修改。 涉及粘贴（粘贴代码而无法进行相应修改的情况并不罕见）。
这就是我要做的：我编写测试用例，然后重构以具有处理模式的类层次结构，然后重新运行测试以确保我没有破坏任何内容。 听起来像是个计划？
You'd rather refactor this using Replace Conditional with Polymorphism.
Writing a test case for these lines will prove that the "if...then...else" statement is returning the correct modeObject, but I wouldn't spend much time on it. It may not be completely pointless, though: if you plan to add new modes the test will ensure that they would be handled as expected, expecially if there's going to be some cut & paste involved (it's not unusual to paste the code and fail to modify it accordingly).
That's what I would do: I'd write the test case(s), then refactor to have a hierarchy of classes handling the modes, and then re-run the tests to make sure I didn't break anything. Sounds like a plan?
添加
Else似乎足够合理。 如果您使用内置的 Visual Studio 单元测试，实际上有一个属性来指示您希望测试成功抛出异常：ExpectedExceptionAttribute。Adding the
Elseseems reasonable enough. If you use the built-in Visual Studio unit testing, there is actually an attribute to indicate that you expect a test to throw an exception for success:ExpectedExceptionAttribute.