如何组织实时数据完整性测试和代码单元测试？
我有几个包含代码测试代码的文件（使用“unittest”类）。
后来我发现测试数据库完整性也很好。我将其放入一个单独的目录树中。 （像键的格式正确，父节点和子节点指向正确等等。编辑：这是一个 nosql 项目，我不能依赖数据库级别检查等引用完整性。）
我使用相同的单元测试类完整性测试。
现在我想知道将其分开是否真的有意义。为了测试数据的完整性，我经常复制用于测试处理数据的代码的部分代码。
但它不一样。代码测试使用测试数据库（每次测试后都会删除），完整性测试连接到实时数据并对其进行分析。我想从 cron 调用完整性测试，并在实时数据库中发生某些情况时发送警报。
你会怎么处理？这样的设置有标准吗？你的经验是什么？
我的倾向是将所有内容都放在同一个文件中，这将导致代码测试也由生产环境中的 cron 执行。
编辑：促使我努力保持项目简单并且不要让单个任务或工作流程涉及太多文件。没有所有的测试，我已经有了一个类文件、一个子类、一个相关的类、一些库（帮助程序）文件和主代码。测试添加一个文件。它帮助我在编码时保持注意力集中，压力更小，我相信我犯的错误更少，而且我可以更快地记住和找到特定的代码部分，受影响的文件更少。每个工作流程只有一个测试文件会有所帮助。如果我将其分开，则有 2 个文件（数据完整性测试和代码测试），也许还有 3 个文件（两者的通用库）。抽象会增加复杂性。
Edit2：我现在正在重构一点，仅将数据测试文件移动到代码测试所在的同一目录树，但保留名称指示“完整性”或“测试”的不同文件。我（还）不会合并这些文件，因为有 2 个人建议反对，我现在相信他们的经验和建议。我暂时会忍受代码重复。
Edit3：我忘了提及，在这种情况下，每次运行的测试选择不是由树结构决定的。测试枚举在一个主文件中，因此我目前有两个主文件“完整性”和“代码测试”，并且测试可以位于相同的目录结构中。
也许更多人会回答。感谢您迄今为止提供的宝贵意见，这已经帮助我开发了最终的结构！
Edit4：我现在做了更多的重构。看来我应该保留 2 个文件，但目的稍作修改。一种针对生产服务器上的计划监控。还有一个用于开发。但在这两个文件中都可以进行完整性测试或代码测试。在这两个文件中，都可以对测试数据库（测试后删除）和永久数据库（每个数据库都有一个永久数据库、生产服务器和开发服务器）执行操作。一件重要的事情：我发现自己将大量通用代码从测试文件移到了类文件中。因此，这些课程还获得了仅用于测试的能力。到目前为止我很喜欢这个，感觉很干净。我（还）没有创建一个在两个测试前端之间共享的测试库，此代码已转到目前正在测试的对象的类文件中。
请注意，我下面的评论署名是“user89021”，但这是我，karlthorwald。我对此无能为力。
I have several files with code testing code (which uses a "unittest" class).
Later I found it would be nice to test database integrity also. I put this into a separate directory tree. (Things like the keys have correct format, parent and child nodes are pointing correctly and such. Edit: this is a nosql project, where I can not rely on database level checks liek referential integrity and such.)
I use the same unittest class for the integrity tests.
Now I wonder if it makes really sense to keep this separate. To test the integrity of data I often duplicate parts of code that I use to test the code that handles the data.
But it is not the same. The code tests use test databases (that get deleted after each test) and the integrity tests connect to the live data and analyze it. The integrity tests I want to call from cron and send an alarm if something happens in the live database.
How would you handle that? Are there standards for such a setup? What is your experience?
My tendency is to put everything in the same file, which would result in the code tests also being executed by the cron on the production environment.
Edit: What also drives me is to try to keep the project simple and not to have too many files touched by a single task or workflow. Without all the testing i already have a class file, a subclass, a related class, some library (helper) files and the main code. Testing adds one file. It helps me keep my attention focussed while coding, it is less stressing and I believe I make less errors, and I can faster remember and find a certain code part with less files affected. Only one testing file per workflow would help here. If I keep it seperate there are 2 files (data integrity testing and code testing) and maybe 3 (a common library for both). Abstraction would add complexity.
Edit2: I am now refactoring a little bit and only moving the data testing files to the same directory tree where also the code testing lives, but keeping different files with the name indicating "integrity" or "testing". I will not (yet) merge the files, because 2 people recommended against it, and I believe in their experience and advice for now. I will live with code duplication for the moment.
Edit3: I forgot to mention that the selection of the tests per run is not determined by the tree structure in this case. The tests are enumerated in a master file, so I have 2 master files "integrity" and "code testing" at the present, and the test can live in the same directury structure.
Maybe more people will answer. Thank you so far for the valuable input, which is already helping me develop the final structure!
Edit4: I did more refactoring now. It seems I should keep 2 files, but with slightly modified purpose. One targeted for scheduled monitoring on the production server. And another one for development. But in both files can be integrity tests or code tests. And in both files operations can be performed on test databases (that are erased after the test) and on the permanent database (each one has a permanent database, production server and develpment server). And one important thing: I find myself moving lots of common code from the testing files to the class files. So the classes get also abilities that are for testing only. I like this so far, feels clean. I am not (yet) creating a library for testing that is shared between the 2 testing frontends, this code has gone to the class file of the obejct that is being teted for now.
Please note that my comments below are signed with "user89021" but it's me, karlthorwald. I can't do anything about it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您应该将数据库相关测试与“纯”单元测试分开。
考虑到好处，拥有两个不同程序集的成本非常低 - 您拥有一套可以在任何计算机上运行的快速、无需环境集的测试，以及一套较慢的套件，用于测试只能在特定位置运行的数据库完整性（例如构建服务器）。
另一个好处是您可以有两个运行不同测试套件的构建过程（快速和夜间）。
为了避免重复代码，您可以使用两个测试套件所需的通用方法/操作创建另一个程序集。不要太担心重复实际测试，因为您正在测试不同的东西（逻辑或数据库），因此您的测试迟早会变得非常不同，具体取决于您要测试的内容。
You should separate the database related tests from the "pure" unit tests.
The cost of having two different assemblies is very low considering the benefits - you have one suite of fast, no environment set required tests that you can run on any machine and a slower suite that tests the database integrity that can run only on specific places (e.g. build server).
Another benefit is that you can have two build processes (quick and nightly) that runs different tests suites.
To avoid duplicating code you can create another assembly with the common methods/actions that both test suites needs. Don't worry too much about duplicatimng the actual tests because you're testing different things (either logic or database) so sooner or later your tests will become quite different depending on what you're trying to test.
你把它们分开的方法很好。
您对代码重复的担忧是 100% 有效的。
解决方案相当简单 - 将测试之间的通用功能 - 例如“RunTest”、“AnalyzeResult”、“ConnectToDB” - 抽象到一个通用库中（您没有指定哪种语言，但我假设它有一个库的概念）可以传递配置详细信息，例如连接到哪个数据库。
然后独立于单元测试驱动程序和完整性测试驱动程序使用该库 - 如果您足够熟练/足够幸运，除了配置之外，它自己的代码可能很少（例如要连接到哪个数据库，如何报告结果，以及要运行哪些测试）。
同样，如果需要，可以将公共输入/数据集放置在公共目录中
Your approach of separating them is good.
Your concern about code duplication is 100% valid.
The solution is fairly straightfowrard - abstract away common functionality between the tests - e.g. "RunTest", "AnalyzeResult", "ConnectToDB" - into a common library (you did not specify which language but I assume it has a concept of a library) which can be passed configration details such as which database to connect to.
Then use that library independently from the unit test driver and integrity test driver - which, if you are skilled/lucky enough, might have very little code of its own other than configuration (e.g. which database to connect to, how to report results, and which tests to run).
Similarly, if needed, common inputs/datasets can be placed in common directory
还有一个答案。您有两种类型的测试。我想做的是解决完整性测试。您可能想要做的是将完整性测试作为生产代码的函数包含在内。 IOW，作为系统的一部分具有完整性。
您已经提到重复是一个问题，并且您正在重构以删除重复。重构后的代码当然有开发测试吗？
系统监控可以是生产代码。因此，您编写的任何代码都会成为系统的一部分。
这样做的好处是您可以通过开发测试来改进代码。
One more answer. You have two types of tests. What I would like to do is address the integrity tests. What you may want to do is include the integrity tests as a function of the production code. IOW, have the integrity as part of the system.
You already mentioned that duplication is an issue and that you are refactoring to remove the duplication. The refactored code of course has development tests?
System Monitoring can be production code. So what ever code you write becomes part of the system.
The nice thing about this is that you evolve your code through your development tests.