这是一个干净的 BDD/MSpec 测试吗?
我有一个静态类Cryptographic
,它可以加密
和解密
字符串。我为此编写了以下规范:
[Subject(typeof(Cryptographic))]
class When_encrypting_and_decrypting_a_string
{
Establish context = () => { input = "teststring"; };
Because of = () =>
{
output = Cryptographic.Decrypt(Cryptographic.Encrypt(input));
};
It should_decrypt_what_was_encrypted = () => input.ShouldEqual(output);
static string input;
static string output;
}
[Subject(typeof(Cryptographic))]
class When_encrypting_and_decrypting_an_empty_string
{
Establish context = () => { input = string.Empty; };
Because of = () =>
{
output = Cryptographic.Decrypt(Cryptographic.Encrypt(input));
};
It should_decrypt_what_was_encrypted = () => input.ShouldEqual(output);
static string input;
static string output;
}
[Subject(typeof(Cryptographic))]
class When_encrypting_and_decrypting_a_null_string
{
Establish context = () => { input = null; };
Because of = () =>
{
output = Cryptographic.Decrypt(Cryptographic.Encrypt(input));
};
It should_decrypt_what_was_encrypted = () => input.ShouldEqual(output);
static string input;
static string output;
}
这是一个干净的 BDD 单元测试吗?有什么可以改进的吗? 我这边有一些担忧:
- 我可能在这里测试两件事,我实际上应该测试的地方 一。我在
Because
中同时拥有Encrypt
和Decrypt
。 - 该测试涉及大量复制和粘贴,所有测试仅因其输入参数而有所不同。也许可以或应该改进这一点 通过使用某种行测试,或公共基类或 而是
Behaves
子句?我的意思是可读性现在相当理想 但可维护性则不然。如果我优化可维护性(DRY)我 可能会以可读性为代价。
您将如何为此编写测试/规范?
I have a static class Cryptographic
that can Encypt
and Decrypt
a string. I have written the following specs for this:
[Subject(typeof(Cryptographic))]
class When_encrypting_and_decrypting_a_string
{
Establish context = () => { input = "teststring"; };
Because of = () =>
{
output = Cryptographic.Decrypt(Cryptographic.Encrypt(input));
};
It should_decrypt_what_was_encrypted = () => input.ShouldEqual(output);
static string input;
static string output;
}
[Subject(typeof(Cryptographic))]
class When_encrypting_and_decrypting_an_empty_string
{
Establish context = () => { input = string.Empty; };
Because of = () =>
{
output = Cryptographic.Decrypt(Cryptographic.Encrypt(input));
};
It should_decrypt_what_was_encrypted = () => input.ShouldEqual(output);
static string input;
static string output;
}
[Subject(typeof(Cryptographic))]
class When_encrypting_and_decrypting_a_null_string
{
Establish context = () => { input = null; };
Because of = () =>
{
output = Cryptographic.Decrypt(Cryptographic.Encrypt(input));
};
It should_decrypt_what_was_encrypted = () => input.ShouldEqual(output);
static string input;
static string output;
}
Is this a clean BDD unittest? Is there anything that can be improved?
A couple of concerns from my side:
- I might be testing two things here, where I actually should test
one. I have bothEncrypt
andDecrypt
in theBecause
. - The test involve a lot of copy and paste, all the test only differ by its input argument. Can or should this be improved, maybe
by using some sort of row test, or a common base class or aBehaves
clause instead? I mean readability is now pretty optimal
but maintainability is not. If I optimize maintainability (DRY) I
might be trading in readability.
How would you write the tests/specs for this?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
这个单元测试看起来是一个很好的起点。我想知道如果我实现
Encrypt
和Decrypt
以便它只返回其各自的input
,它是否会中断。目前,不需要加密任何东西,这让我怀疑是否先编写了测试代码或生产代码。作为一般规则,如果您需要测试输入和输出对,我建议查看 NUnit 的 TestCase 等。等人。 BDD 作为一种工具特别有意义,但不限于指定系统行为。您在这里展示的是一个不与系统的任何其他部分交互的单个类。虽然我知道 BDD 和上下文/规范风格可能有助于表达预期的单元行为,但有时经典的单元测试框架更有意义。如果您需要对输入和输出元组进行测试运行,则尤其如此。
This unit test looks like a good starting point. I wonder if it would break if I implemented
Encrypt
andDecrypt
such that it just returns its respectiveinput
. Currently, there's no need to encrypt anything which makes me wonder whether the test or the production code have been written first.As a general rule, if you need to test pairs of input and output, I suggest to have a look at NUnit's
TestCase
et. al. BDD as a tool especially makes sense, but is not limited to, specifying system behavior. What you presented here is a single class that does not interact with any other part of the system. While I understand that BDD and the context/specification flavor might have helped to express the expected unit behavior, sometimes classic unit testing frameworks make more sense. That's especially true if you need a test run for tuples of input and output.