20

这是我的另一个问题的后续。

基本上，一旦我有了访问文件的代码（将在一分钟内查看答案），测试它的最佳方法是什么？

我正在考虑创建一种方法，它只会产生大量BackgroundWorker或其他东西，并告诉它们全部加载/保存文件，并使用不同的文件/对象大小进行测试。然后，从线程中获取响应以查看它是否失败/成功/使世界内爆等。

你们能就解决这个问题的最佳方法提供任何建议吗？正如我之前所说，这对我来说有点新鲜 :)

编辑

在ajmastrean 的帖子之后：

我正在使用控制台应用程序来测试 Debug.Asserts :)

更新

我最初使用BackgroundWorker来处理线程（因为我已经习惯了 Windows 开发人员的线程）我很快意识到，当我执行需要完成多个操作（线程）才能继续进行的测试时，我意识到这将是让它做到这一点有点技巧。

然后我跟进了ajmastrean的帖子，并意识到我真的应该使用Thread类来处理并发操作。我现在将使用这种方法进行重构（尽管方法不同）。

4

3 回答 3

16

在 .NET 中，ThreadPool如果不设置ManualResetEvents 或AutoResetEvents，线程将不会返回。我发现这些对于快速测试方法来说太过分了（更不用说创建、设置和管理的复杂性了）。后台工作者对于回调等也有点复杂。

我发现有用的东西是

  1. 创建线程数组。
  2. 设置ThreadStart每个线程的方法。
  3. 启动每个线程。
  4. 加入所有线程（阻塞当前线程，直到所有其他线程完成或中止） 
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();
    }
}
于 2008-09-03T12:52:52.613 回答
1

@ajmastrean，因为单元测试结果必须是可预测的，我们需要以某种方式同步线程。如果不使用事件，我看不到一种简单的方法。

我发现这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");
    }
});
于 2008-09-03T13:06:50.863 回答
-2

你的想法应该可以正常工作。基本上，您只想生成一堆线程，并确保编写文件的线程需要足够长的时间才能真正让读者等待。如果你所有的线程都没有错误地返回，并且没有永远阻塞，那么测试就成功了。

于 2008-09-03T12:45:55.923 回答