您如何管理项目中的单元测试文件?你在git中添加它们吗?
您如何管理项目中的 PHPUnit 文件?
您是将其添加到您的 git 存储库还是忽略它们?
您是否在 PHPdocs 代码中使用 @assert 标记?
How do you manage your PHPUnit files in your projects?
Do you add it to your git repository or do you ignore them?
Do you use @assert tag in your PHPdocs codes?
推荐答案
设置
我目前没有使用 php，但我正在使用 python 单元测试 和 git 中的 sphinx 文档.我们将测试添加到 git 中，甚至对推送到远程 devel 和 master 分支的测试通过有一定的要求(master 比 开发).这保证了一些代码质量(测试覆盖率也应该被评估，但那还没有实现:)).
Setup
I'm not using php currently, but I'm working with python unit testing and sphinx documentation in git. We add our tests to git and even have certain requirements on test passing for pushing to the remote devel and master branches (master harder than devel). This assures a bit of code quality (test coverage should also be evaluated, but thats not implemented yet :)).
我们有 测试文件位于顶级源目录旁边的单独目录中它们所属的目录，以 test_ 为前缀，以便单元测试框架自动找到它们.
We have the test files in a separate directory next to the top-level source directory in the directories where they belong to, prefixed with test_, so that the unit testing framework finds them automagically.
对于类似的文档，我们只是将 sphinx docs 文件放到它们自己的子目录 (docs) 中，在我们的例子中是一个独立的 git 子模块，将来可能会更改.
For documentation its similar, we just put the sphinx docs files into their own subdirectory (docs), which is in our case an independent git submodule, which might be changed in the future.
我们希望能够跟踪测试中的变化，因为它们应该很少见.频繁更改表明代码不成熟.
We want to be able to track changes in the tests, as they should be rare. Frequent changes indicate immature code.
其他团队成员需要访问测试，否则他们将毫无用处.如果他们在某些地方更改代码，他们必须能够验证它不会破坏任何东西.
Other team members need access to the tests, otherwise they're useless. If they change code in some places, they must be able to verify it doesn't break anything.
文档属于代码.在 python 的情况下，代码直接包含文档.所以我们必须把它们放在一起，因为文档是从代码生成的.
Documentation belongs to the code. In case of python, the code directly contains the documentation. So we have to keep it both together, as the docs are generated from the code.
在存储库中拥有测试和文档允许在远程服务器上进行自动化测试和文档构建，这为我们提供了即时更新的文档和测试反馈.同样，基于测试结果的代码质量"限制的实现也是如此(它实际上更多地提醒人们运行测试，因为如果不查看测试覆盖率就无法通过测试检查代码质量).如果测试未通过，则 git 服务器会拒绝 Refs.
Having the tests and the docs in the repository allows for automated testing and doc building on the remote server, which gives us instantaneous updated documentation and testing feedback. Also the implementation of "code quality" restrictions based on test results works that way (its actually more a reminder for people to run tests, as code quality cannot be checked with tests without looking at test coverage too). Refs are rejected by the git server if tests do not pass.
例如，我们要求在 master 上，所有测试都必须通过或被跳过(遗憾的是，我们需要跳过，因为某些测试需要 OpenGL，而这在 headless 上不可用)，而在 devel 如果测试只是表现得像预期的那样"(即通过、跳过或预期失败，没有意外成功、错误或失败)，那也没关系.
We for example require that on master, all tests have to pass or be skipped (sadly, we need skipped, as some tests require OpenGL, which is not available on headless), while on devel its okay if tests just "behave like expected" (i.e. pass, skip or expected failure, no unexpected success, error or failure).
相关文章