我应该将与正在测试的代码相关的测试代码放在哪里？
我能想到的两个明显的地方是我正在处理的代码旁边的某种“测试”文件夹。比如：
\project-code
\my-feature
\production-code
\testing
***my tests***
\co-workers-feature
\production-code
\testing
或者我可以将测试代码拆分为一个完全独立的层次结构。就像这样：
\project-code
\my-feature
\co-workers-feature
\testing-project-code
\my-feature
***my tests***
\co-workers-feature
我看到很多框架都使用第二种方法，但最近我们将测试代码放在生产代码中主要是为了方便。一种方法比另一种方法好得多还是这里有最佳实践？
The two obvious places I can think of would be some sort of "testing" folder right next to the code I'm working on. So something like:
\project-code
\my-feature
\production-code
\testing
***my tests***
\co-workers-feature
\production-code
\testing
Or I could split out the testing code a completely separate hierarchy. So something like:
\project-code
\my-feature
\co-workers-feature
\testing-project-code
\my-feature
***my tests***
\co-workers-feature
I've seen a lot of frameworks use the second approach, but recently we've been putting our testing code within the production code mostly for convenience. Is one approach much better than the other or is there a best practice here?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
如果它是您控制的网站，那么将其全部放在同一个文件夹中也没有什么坏处。如果您发布的是经典软件，那么像情况 2 那样将其分开往往是一个很好的做法，这样您在发布时就不会意外地导致任何膨胀。
If its a website that you control then it does not hurt to have it all in the same folder. If its classic software that you release then it tends to be good practice to have it seperate as in case 2 so that you don't accidently cause any bloat when you release.
对我来说，第一个选项更有意义，特别是从 SCM 的角度来看：生产代码和测试代码很好地保持同步（正如它们应该的那样），并且，如果您标记或分支您的项目，则您可以标记或分支生产和测试代码。同时测试代码（正如他们应该的那样）。
To me, the first option makes more sense, especially from a SCM point of view: production code and testing code are nicely kept in sync (as they should) and, if you tag or branch your project, you tag or branch both production and test code in the same time (as they should).
将它们放在您最方便的地方。如果需要，您可以设置构建系统以将它们从最终产品中删除。测试是“最佳实践”。任何使测试变得更容易而不降低其有效性的方法都只是对最佳实践的改进。
Put them where it is most convenient for you. You can set up your build system to remove them from the final product, if desired. Testing is a "best practice". Anything that makes testing easier without reducing its effectiveness is simply improving on a best practice.
我使用第二个选项。这意味着如果需要的话，我可以在不进行测试的情况下发布代码。另外，通过查看类或包，我知道它的单元测试在哪里。
这是一个相关的问题：
你是否放置单元测试在同一个项目还是另一个项目中？
I use the second option. That means I can ship the code without the tests if needed. Also from looking at the class or package I know where the unit tests for it are.
Here's a related question:
Do you put unit tests in same project or another project?
我更喜欢保持单元测试紧密。我发现选项 1 效果很好。对于小型项目，这两种方法都可以正常工作，但随着项目变得越来越大，当测试位于树的不同部分时，找到和维护测试就变得更加困难。如果它们很接近，那么当您更改产品代码时，更改它们就会很自然。如果距离较远，则需要花费更多的精力，并且会更容易被忽视。这意味着它们不同步的可能性更大。
请注意，要执行此操作，您需要一个允许对测试目录进行条件编译的 make 系统。您不想每次都构建它们。如果您无法做到这一点，则可能需要一棵单独的树。
I prefer to keep unit tests close. I have seen option 1 work well. For a small project, both approaches will work fine, but as the project gets bigger and bigger, it is harder to find and maintain the tests when they live in a very different part of the tree. If they are close, changing them will be natural when you change the product code. If they are far away, it takes more mental effort and will be ignored more. This means a greater chance that they will be out of sync.
Note that to do this you need a make system that allows for conditional compilation of the test directories. You don't want to have to build them every time. If you can't get that, a separate tree might be necessary.