如何为我的测试用例构建批处理作业 [英] how to build batch job for my test case

问题描述

我为Windows用户控件手动构建了许多测试用例。这些测试用例是针对用户控件项目构建的。



我模糊了我的用户控件之后，我想针对我的模糊用户控件构建这些相同的测试用例并测试我的如果工作混淆了DLL。



构建针对这个混淆的DLL的测试用例的最佳方法/架构是什么？



我的所有测试用例都存储在我的版本控制系统中，与我的用户控制项目分开。



非常感谢!!!

解决方案

请参阅我对该问题的评论。



这里唯一重要的部分是混淆。问题的解决方案很简单：您应该在混淆之前进行所有测试。根据定义，混淆不应该改变代码的任何属性。但是，代码应该是正确的并且是混淆容忍的。基于某些类型和成员的硬编码名称的代码非常流行且根本错误，可维护性差（这些名称可以用于反射，使用.NET属性或不使用它们）。存在这样的问题，但与测试问题无关。



关于混淆的更多信息：如果你希望保护你的代码免受修改和模仿，请不要你的呼吸。对代码进行反向工程很容易。混淆使得理解变得更加困难，但并不能真正防止修改，例如取消许可证检查等。

-SA

I have manually built many test cases for my windows user control. these test cases are built against user control project.

after I obfuscated my user control, I want to build these same test cases against my obfuscated user control and test if my obfuscated DLL if works.

what is the best way/architecture to build my test cases against this obfuscated DLL?

all my test cases are stored in my version control system and is separate with my user control project.

Thank you very much!!!

解决方案

Please see my comment to the question.

The only essential part here is the obfuscation. The solution of the problem is simple: you should do all the tests before obfuscation. Obfuscation, by definition, should not change any properties of the code. However, the code should be correct and obfuscation-tolerant. The code based on hard-coded names of some types and members is very popular and fundamentally wrong, poorly maintainable (such names then can be used in reflection, with the use of .NET attributes or without them). Such problem exist, but is unrelated to the problem of testing.

More about obfuscation: if you hope to protect your code from modification and the copycat, don't hold your breath. It's way too easy to reverse-engineer your code. Obfuscation makes it harder to understand, but does not really protect from modifications, such as elimination of license check and the like.

—SA

这篇关于如何为我的测试用例构建批处理作业的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！