使用 .NET 的 Fitnesse 在运行套件时神秘地卡住了

发布于 2024-09-09 04:28:55 字数 2412 浏览 4 评论 0原文

(当然,我可以说这是“神秘的”,因为我无法找出问题所在。我希望这对你们中的一位博学读者来说是显而易见的,并且您可以启发我:-)

在我的浏览器(FireFox 或 IE)中运行单个 Fitnesse 测试效果很好,但是当我运行一套或一组测试时,Fitnesse 在开始后很快就会停止在某个地方。它从不报告测试完成;它只是挂起。

我在 Windows XP 上针对 .NET 3.5 代码库运行fitnesse。我首先通过使用诊断代码对fitnesse测试和fitnesse装置进行检测来解决这个问题,以尝试确定它是否确实是fitnesse锁定或(更可能是)装置访问了我的代码库。因此,我创建了一些诊断例程,这些例程写入日志文件,以告诉我何时进入和离开每个健身装置。如果日志文件最后报告一个“enter”,表明卡在代码库中;如果日志最后报告指向fitnesse的“离开”。诊断非常简单,需要手动检测每个夹具 - 观察下面框架代码中的 Diagnostic.EnterDiagnostic.Leave 方法。 (Leave 方法的参数让我可以看到异常的文本(如果发生)。)

public class AddFoobarEntityFixture : ColumnFixture
{
    public bool Ok()
    {
        Diagnostic.Enter();
        string exitMessage = null;
        try
        {
            . . .
        }
        catch (Exception exc)
        {
            exitMessage = exc.Message;
            return false;
        }
        finally
        {
            Diagnostic.Leave(exitMessage);
        }
        return true;
    }
}

在对同一测试套件运行一系列试验后,我注意到一些令人惊讶的观察结果:

  1. Run从浏览器来看,fitnesse 输出滞后于测试进度并且(在这种锁定场景中)永远不会跟上。也就是说,在浏览器中,我看到执行的测试表从一个到十几个。另一方面,日志文件显示了相同执行的多达大约 35 个测试表。我怀疑这种滞后与锁定无关,因为网页在锁定发生之前很久就停止更新,其中日志文件继续报告正在执行的测试表。

  2. 锁定发生在随机位置。下面我的粗略条形图显示了近十几个试验(每行一个),水平轴上有时间(或测试表的数量)。每个“X”代表一个已处理的测试表。

    1> XXXXXXXXXXXXXXXXXXXXX
    2> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    3> XXXXXXXXXXXXXXXXXXXXX
    4> XXXXXXXXXXXXXXXXXXXXX
    5> XXXXXXXXXXXXXXXXXXXXXXXX
    6> XXXXXXXXXXXXXXXXXXXXX
    7> XXXXXXXXXXXXXXXXXXXXX
    8> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    9> XXXXXXXXXXXXXXXXXXXXXXXX
    A> XXXXXXXXXXXXXXXXXXXXXXXX
    B> XXXXXXXXXXXXXXXXXXXXXXXX

  3. 无一例外,日志中的每个 Enter 都被 Leave 所平衡。这表明问题出在fitnesse上,而不是在测试的代码上。然而,它确实依赖于两个重要的假设:首先,每个测试夹具都已检测,其次,在每个检测的测试夹具中,只有琐碎的代码位于 Enter-Leave 括号之外(例如,像 return 语句仅返回本地值或具有简单初始化值或无初始化值的变量声明)。我还没有完全审查这两个假设,但我认为它们会被证明是可以的。

我曾希望fitnesse提供自己的日志记录,这样我就可以看到,例如,继承了哪个SetUp或SuiteSetUp、何时处理包含、正在运行哪个测试表等。然而,从我所看到的,唯一的日志记录功能Fitnesse 报告的粒度是整个测试页,这是不幸的。

奇怪的是,我自己的网络搜索完全没有提到其他人在fitnesse中遇到这个问题,当然,这强烈暗示问题出在我的代码库中。

任何有关隔离此问题的建议,无论是在fitnesse中还是在我的代码库中,我们都将不胜感激!


2010.07.15 更新

奇怪的是,我想我解决了这个问题。通过将 Fitnesse 使用的端口从(我认为是)默认的 8080 更改为不太流行的端口号,现在我可以毫无问题地运行测试套件或套件套件。我确实检查了端口 8080 上没有运行其他任何东西(使用 TCPView)。那么有人知道为什么这会产生任何影响吗?

( Of course I can state this is "mysterious" because I have not been able to identify the problem. I am hoping it will be obvious to one of you erudite readers and that you can enlighten me :-)

Running a single fitnesse test in my browser (FireFox or IE) works fine, but when I run a suite of tests or a suite of suites, Fitnesse just stops somewhere very soon after beginning. It never reports test completion; it just hangs.

I am running fitnesse on Windows XP against a .NET 3.5 code base. I first attacked the problem by instrumenting both the fitnesse tests and the fitnesse fixtures with diagnostic code to attempt to determine whether it was indeed fitnesse locking up or (more likely) my code base accessed by the fixtures. So I created some diagnostic routines that write to a log file to tell me when entering and leaving each fitnesse fixture. If the log file last reports an "enter" that points to getting stuck in the code base; if the log last reports a "leave" that points to fitnesse. The diagnostics are quite simple, requiring each fixture to be manually instrumented--observe the Diagnostic.Enter and Diagnostic.Leave methods in the skeleton code below. (The argument to the Leave method lets me see the text of an exception, if one occurs.)

public class AddFoobarEntityFixture : ColumnFixture
{
    public bool Ok()
    {
        Diagnostic.Enter();
        string exitMessage = null;
        try
        {
            . . .
        }
        catch (Exception exc)
        {
            exitMessage = exc.Message;
            return false;
        }
        finally
        {
            Diagnostic.Leave(exitMessage);
        }
        return true;
    }
}

After running a series of trials for the same test suite I noticed a couple startling observations:

  1. Run from a browser, the fitnesse output lags the test progression and (in this lockup scenario) never catches up. That is, in the browser I see anywhere from one to perhaps a dozen test tables executed. The log file, on the other hand, has shown up to about 35 test tables for the same executions. I suspect this lag is unrelated to the lockup because the web page stops updating long before the lockup occurs, where the log file continues to report test tables being executed.

  2. The lockup occurs at random locations. My rough bar chart below shows almost a dozen trials (one per row), with time (or number of test tables) on the horizontal axis. Each "X" represents one test table processed.

    1> XXXXXXXXXXXXXXXXXXXXXXX
    2> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    3> XXXXXXXXXXXXXXXXXXXXXX
    4> XXXXXXXXXXXXXXXXXXXXXXX
    5> XXXXXXXXXXXXXXXXXXXXXXXX
    6> XXXXXXXXXXXXXXXXXXXXXXX
    7> XXXXXXXXXXXXXXXXXXXXXXX
    8> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    9> XXXXXXXXXXXXXXXXXXXXXXXX
    A> XXXXXXXXXXXXXXXXXXXXXXXX
    B> XXXXXXXXXXXXXXXXXXXXXXXX

  3. Without exception, every Enter was balanced by a Leave in the log. This suggests that the problem is with fitnesse rather than the code under test. It does rely on two important assumptions, however: first that every test fixture is instrumented, and second, that within each instrumented test fixture only trivial code is outside the Enter-Leave bracketing (e.g. things like a return statement returning only a local value or a variable declaration with a simple or no initialized value). I have not fully vetted these two assumptions but I think they will prove to be OK.

I had hoped that fitnesse provided its own logging so I could see, for example, which SetUp or SuiteSetUp was inherited, when includes were processed, which test table was being run, etc. From what I have seen, however, the only logging capability of fitnesse reports to the granularity of an entire test page, which is unfortunate.

Curiously, my own web searches have turned up absolutely no mention of others encountering this problem with fitnesse which, of course, strongly intimates the problem lies in my code base somehow.

Any suggestions to isolating this problem, be it in fitnesse or in my code base, are appreciated!


2010.07.15 Update

Strangely enough, I think I fixed the problem. By changing the port that fitnesse uses from (what I think is) the default of 8080 to a less popular port number, now I can run suites of tests or suites of suites without problem. I did check that I had nothing else running on port 8080 (with TCPView). So anyone have any thoughts on why this would make any difference?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

清秋悲枫 2024-09-16 04:28:55

我知道这是一个老问题,但我想我会为未来的观众添加这个问题。

我们在运行套件时遇到问题,结果是新安装的趋势科技防病毒软件(或他们称之为“无忧企业安全”)的问题。

“URL 过滤”功能是该套件的一部分。

你有类似的跑步吗?

I know this is an old question, but thought I would add this for any future viewers.

We had a problem running suites and it turned out to be the newly installed Trend Micro anti-virus (or as they call it "Worry-Free Business Security").

It was the "URL Filtering" functionality that is part this suite.

Do you have anything similar running?

痴情 2024-09-16 04:28:55

试试这个

http://www.asoftwarecraft.com/2010/ 01/troubleshooting-with-fitsharp-and.html

并查看是否发生未处理的异常。

Try this

http://www.asoftwarecraft.com/2010/01/troubleshooting-with-fitsharp-and.html

and see if there's an unhandled exception happening.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文