PHPUnit 和多处理测试
我正在编写一个用于进行多重处理（分叉）的库，并想使用 PHPUnit 对其进行测试。
到目前为止，我想出了以下场景：
- 使要测试的进程作为分叉进程运行 - 因此，如果出现问题，PHPUnit 运行的主进程不会永远卡住（我使用某种时间限制，之后被测试的子进程被杀死）。
- 在测试的进程和由它创建的任何其他子进程中，我确实将所有操作（执行的工作、接收和发送的信号等）记录在某种格式化的日志中，稍后可以轻松处理
- 所有工作完成后在完成 PHPUnit 测试的主流程中，我会读取并处理创建的日志以及我的断言 - 检查是否执行了预期的操作。
与我的场景相比，是否有任何好的/更好的技术来进行测试？
I am writing a library for doing multi-processing (forking) and would like to test it with PHPUnit.
So far I came up with following scenario:
- Making the process to be tested to run itself as a forked process - so if something goes wrong, the main process where PHPUnit is running would not stuck forever (I use some kind of time limit, after which the tested child process is killed).
- In the tested process and any other sub-processes created by it I do log all my actions (performed work, received and sent signals, etc) in a some kind of formatted log, which can be later easy processed
- After all work is done in the main process, where PHPUnit testing is done, I do read and process the created logs and to my assertions - check if expected actions were performed or not.
Are there any would good/better techniques how to do the testing compared to my scenario?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
看看我如何测试 Spork。关键是在运行断言之前调用
pcntl_wait()。Take a look at how I'm testing Spork. The key is to call
pcntl_wait()before running your assertions.我建议您将分叉的测试与分叉进程中完成的工作的测试分开。例如，假设您的程序通过为每个子目录生成一个子进程，然后处理其自己的目录本身中的文件来递归地处理目录。
不是完整地处理一个大型目录树并分析结果输出（仅为测试而创建），而是进行处理文件的测试、使用目录生成子目录的测试、检测目录的测试等 。
当您将每个必须测试的系统规模缩小到较小的工作单元时，您的测试将变得更加容易 当您开始测试子级是否生成时，如果将系统调用放入其自己的方法中，则可以模拟系统调用。
这涵盖了非常高水平的很多内容。如果您需要更多详细信息，请询问具体情况。
I recommend that you separate the testing of the forking from the testing of the work done in the forked process(es). For example, say your program processes a directory recursively by spawning a child process for each subdirectory and then processing the files in its own directory itself.
Instead of processing a large directory tree in its entirety and analyzing the resulting output--created only for the tests no less--have tests for processing a file, tests for spawning a child with a directory, a test that directories are detected, etc.
Your tests will become easier as you shrink the size of the system each must test to small units of work. When you get to testing that children are spawned, you could mock out the system call if you place it into its own method.
This covers a lot at a very high level. Ask for specifics if you need more details.