什么是从多个线程进行unit testing的最佳方法？
这是从我的另一个问题开始的。
基本上，一旦我有代码访问该文件（将在一分钟内审查答案）什么是最好的测试方法？
我正在考虑创建一个方法，它只生成大量的BackgroundWorker或者其他东西并告诉他们所有加载/保存文件，并测试不同的文件/对象大小。 然后，从线程中获取响应以查看它是否失败/成功/使世界崩溃等。
你能提出任何关于最佳方法的建议吗？ 正如我之前所说，这对我来说有点新鲜:)
编辑
关注ajmastrean的post：
我正在使用控制台应用程序来测试Debug.Asserts 🙂
更新
我最初使用BackgroundWorker来处理线程（因为我已经习惯了来自Windows开发）我很快就意识到当我执行多个操作（线程）需要在继续之前完成的测试时，我意识到它将会是让它做到这一点有点破解。
然后我跟进了ajmastrean的post并意识到我应该使用Thread类来处理并发操作。 我现在将使用这种方法进行重构（虽然是一种不同的方法）。
在.NET中，如果不设置ManualResetEvent或AutoResetEvent ， ThreadPool线程将不会返回。 我发现这些过度杀伤是一种快速的测试方法（更不用说创建，设置和管理的复杂程度）。 后台工作者也有一些复杂的回调等。
我找到的东西是有效的
- 创建一个线程数组。
- 设置每个线程的
ThreadStart方法。 - 启动每个线程。
- 加入所有线程（阻塞当前线程，直到所有其他线程完成或中止）
public static void MultiThreadedTest() { Thread[] threads = new Thread[count]; for (int i = 0; i < threads.Length; i++) { threads[i] = new Thread(DoSomeWork()); } foreach(Thread thread in threads) { thread.Start(); } foreach(Thread thread in threads) { thread.Join(); } }
@ajmastrean，因为unit testing结果必须是可预测的，我们需要以某种方式同步线程。 在没有使用事件的情况下，我看不到一种简单的方法。
我发现ThreadPool.QueueUserWorkItem为我提供了一种测试此类用例的简便方法
ThreadPool.QueueUserWorkItem(x => { File.Open(fileName, FileMode.Open); event1.Set(); // Start 2nd tread; event2.WaitOne(); // Blocking the file; }); ThreadPool.QueueUserWorkItem(x => { try { event1.WaitOne(); // Waiting until 1st thread open file File.Delete(fileName); // Simulating conflict } catch (IOException e) { Debug.Write("File access denied"); } });
你的想法应该工作正常。 基本上你只想生成一堆线程，并确保编写文件的人花费足够长的时间来实际让读者等待。 如果所有线程都没有错误地返回，并且没有永久阻塞，则测试成功。