單元測試過多，導致The configured user limit (128) on the number of inotify instances has been reached.

最近在一個asp.net core web項目中使用TDD的方式開發，結果單元測試超過128個之後，在CI中報錯了：“The configured user limit (128) on the number of inotify instances has been reached.” 在本地卻是正常的，如此詭異的事，必定要搞清楚。

於是，從報錯信息著手，一番Google無果之後，不得不冷靜思考，報錯的原因在哪裡？通過異常信息定位到了是因為在測試中，每個測試都要開啟一個TestServer，相當於運行一個站點，在站點Setup的時候，需要監聽配置文件，在unix系統中是通過一個inotify的東西實現監聽的，因此當監聽那個配置文件的次數達到系統上限（CI伺服器是128）就會拋出一個IO異常，而在本地卻沒有達到上限，因此是正常的。

既然問題的原因找到了，那麼解決問題的思路也就明確了。

方案一：把CI伺服器的限制調高

方案二：減少集成測試中開啟TestServer的次數

對比這兩種方案，第二種是最優解。

一般在跨平臺的core中，我們大多使用xunit框架進行測試，在xunit官方文檔中，我發現有一節“Shared Context between Tests”，在各個測試中共用一個上下文，大家對上下文的概念應該不陌生，“It is common for unit test classes to share setup and cleanup code (often called "test context"). ”這裡是指單元測試中需要共用的啟動和清除代碼，在我的項目中就是每個測試都需要開啟的TestServer（運行asp.net core web站點服務），只要把TestServer放在上下文中就可以在單元測試中共用，不需要每個測試開啟一次，那麼就會大大減少TestServer的實例個數。

稍微註意一點：在xunit框架中，單元測試預設是Test Collections級別的併發測試，預設一個類算一個Test Collections，那麼類與類之間是併發的，而一個類中的所有的單元測試是串列的。當然所有的預設值都能自定義，詳見：https://xunit.github.io/docs/running-tests-in-parallel.html

實現我們的解決方案，其實很簡單，就是使用xunit中的IClassFixture<>，下麵引用一個官方文檔中的例子，

public class DatabaseFixture : IDisposable
{
    public DatabaseFixture()
    {
        Db = new SqlConnection("MyConnectionString");

        // ... initialize data in the test database ...
    }

    public void Dispose()
    {
        // ... clean up test data from the database ...
    }

    public SqlConnection Db { get; private set; }
}

public class MyDatabaseTests : IClassFixture<DatabaseFixture>
{
    DatabaseFixture fixture;

    public MyDatabaseTests(DatabaseFixture fixture)
    {
        this.fixture = fixture;
    }

    // ... write tests, using fixture.Db to get access to the SQL Server ...
}

在MyDatabaseTests中的所有單元測試都會共用一個DatabaseFixture實例。

然而，在我的項目中，使用了ABP框架，它封裝的AbpAspNetCoreIntegratedTestBase<>並不能直接用IClassFixture<>，因此只能把ABP的源碼簽下來，自己修改一下，然後打包成Nuget包，發佈到自己的源中。最後，順便給ABP提交一個PullRequest