通過JUnit源碼分析學習編程的奇技淫巧

来源:https://www.cnblogs.com/wgjava/p/18354483
-Advertisement-
Play Games

V哥在 JUnit 框架源碼學習時總結的13個非常值得學習的點，希望也可以幫助到你提升編碼的功力，歡迎關註威哥愛編程，一起學習框架源碼，提升編程技巧，我是 V哥，愛 編程，一輩子。 ...


打開 Maven倉庫，左邊選項欄排在第一的就是測試框架與工具，今天的文章，V 哥要來聊一聊程式員必備的測試框架JUnit 的源碼實現，整理的學習筆記，分享給大家。

有人說，不就一個測試框架嘛，有必要去瞭解它的源碼嗎？確實，在平時的工作中，我們只要掌握如何使用 JUnit 框架來幫我們測試代碼即可，搞什麼源碼，相信我，只有看了 JUnit 框架的源碼，你才會贊嘆，真是不愧是一款優秀的框架，它的源碼設計思路與技巧，真的值得你好好研讀一下，學習優秀框架的實現思想，不就是優秀程式員要乾的事情嗎。

JUnit 是一個廣泛使用的 Java 單元測試框架，其源碼實現分析可以幫助開發者更好地理解其工作原理和內部機制，並學習優秀的編碼思想。

JUnit 框架的源碼實現過程中體現了多種優秀的設計思想和編程技巧，這些不僅使得 JUnit 成為一個強大且靈活的測試框架，也值得程式員在日常開發中學習和借鑒。V 哥通過研讀源碼後，總結了以下是一些關鍵點：

  1. 面向對象設計：JUnit 充分運用了面向對象的封裝、繼承和多態特性。例如，TestCase 類作為基類提供了共用的測試方法和斷言工具，而具體的測試類繼承自 TestCase 來實現具體的測試邏輯。

  2. 模板方法模式：JUnit 的 TestCase 類使用了模板方法設計模式，定義了一系列模板方法如 setUp()、runTest() 和 tearDown()，允許子類重寫這些方法來插入特定的測試邏輯。

  3. 建造者模式：JUnit 在構造測試套件時使用了建造者模式，允許逐步構建複雜的測試結構。例如，JUnitCore 類提供了方法來逐步添加測試類和監聽器。

  4. 策略模式：JUnit 允許通過不同的 Runner 類來改變測試執行的策略，如 BlockJUnit4ClassRunner 和 Suite。這種設計使得 JUnit 可以靈活地適應不同的測試需求。

  5. 裝飾者模式：在處理測試前置和後置操作時，JUnit 使用了裝飾者模式。例如，@RunWith 註解允許開發者指定一個 Runner 來裝飾測試類，從而添加額外的測試行為。

  6. 觀察者模式：JUnit 的測試結果監聽器使用了觀察者模式。多個監聽器可以訂閱測試事件，如測試開始、測試失敗等，從而實現對測試過程的監控和結果的收集。

  7. 依賴註入：JUnit 支持使用註解如 @Mock 和 @InjectMocks 來進行依賴註入，這有助於解耦測試代碼，提高測試的可讀性和可維護性。

  8. 反射機制：JUnit 廣泛使用 Java 反射 API 來動態發現和執行測試方法，這提供了極大的靈活性，允許在運行時動態地構建和執行測試。

  9. 異常處理：JUnit 在執行測試時，對異常進行了精細的處理。它能夠區分測試中預期的異常和意外的異常，從而提供更準確的測試結果反饋。

  10. 解耦合：JUnit 的設計註重組件之間的解耦，例如，測試執行器（Runner）、測試監聽器（RunListener）和測試結果（Result）之間的職責清晰分離。

  11. 可擴展性：JUnit 提供了豐富的擴展點，如自定義的 Runner、TestRule 和 Assertion 方法，允許開發者根據需要擴展框架的功能。

  12. 參數化測試：JUnit 支持參數化測試，允許開發者為單個測試方法提供多種輸入參數，這有助於用一個測試方法覆蓋多種測試場景。

  13. 代碼的模塊化：JUnit 的源碼結構清晰，模塊化的設計使得各個部分之間的依賴關係最小化，便於理解和維護。

通過學習和理解 JUnit 框架的這些設計思想和技巧，程式員可以在自己的項目中實現更高質量的代碼和更有效的測試策略。

1. 面向對象設計

JUnit 框架的 TestCase 是一個核心類，它體現了面向對象設計的多個方面。以下是 TestCase 實現過程中的一些關鍵點，以及源碼示例和分析：

  1. 封裝：TestCase 類封裝了測試用例的所有邏輯和相關數據。它提供了公共的方法來執行測試前的準備 (setUp) 和測試後的清理 (tearDown)，以及其他測試邏輯。
public class TestCase extends Assert implements Test {
    // 測試前的準備
    protected void setUp() throws Exception {
    }

    // 測試後的清理
    protected void tearDown() throws Exception {
    }

    // 運行單個測試方法
    public void runBare() throws Throwable {
        // 調用測試方法
        method.invoke(this);
    }
}
  1. 繼承：TestCase 允許其他測試類繼承它。子類可以重寫 setUp 和 tearDown 方法來執行特定的初始化和清理任務。這種繼承關係使得測試邏輯可以復用，並且可以構建出層次化的測試結構。
public class MyTest extends TestCase {
    @Override
    protected void setUp() throws Exception {
        // 子類特有的初始化邏輯
    }

    @Override
    protected void tearDown() throws Exception {
        // 子類特有的清理邏輯
    }

    // 具體的測試方法
    public void testSomething() {
        // 使用斷言來驗證結果
        assertTrue("預期為真", someCondition());
    }
}
  1. 多態：TestCase 類中的斷言方法 (assertEquals, assertTrue 等) 允許以不同的方式使用，這是多態性的體現。開發者可以針對不同的測試場景使用相同的斷言方法，但傳入不同的參數和消息。
public class Assert {
    public static void assertEquals(String message, int expected, int actual) {
        // 實現斷言邏輯
    }

    public static void assertTrue(String message, boolean condition) {
        // 實現斷言邏輯
    }
}
  1. 抽象類：雖然 TestCase 不是一個抽象類，但它定義了一些抽象概念，如測試方法 (runBare)，這個方法可以在子類中以不同的方式實現。這種抽象允許 TestCase 類適應不同的測試場景。
public class TestCase {
    // 抽象的測試方法執行邏輯
    protected void runBare() throws Throwable {
        // 預設實現可能包括異常處理和斷言調用
    }
}
  1. 介面實現：TestCase 實現了 Test 介面，這表明它具有測試用例的基本特征和行為。通過實現介面，TestCase 保證了所有測試類都遵循相同的規範。
public interface Test {
    void run(TestResult result);
}

public class TestCase extends Assert implements Test {
    // 實現 Test 介面的 run 方法
    public void run(TestResult result) {
        // 運行測試邏輯
    }
}

我們可以看到 TestCase 類的設計充分利用了面向對象編程的優勢，提供了一種靈活且強大的方式來組織和執行單元測試。這種設計不僅使得測試代碼易於編寫和維護，而且也易於擴展和適應不同的測試需求，你get 到了嗎。

2. 模板方法模式

模板方法模式是一種行為設計模式，它在父類中定義了演算法的框架，同時允許子類在不改變演算法結構的情況下重新定義演算法的某些步驟。在 JUnit 中，TestCase 類就是使用模板方法模式的典型例子。

以下是 TestCase 類使用模板方法模式的實現過程和源碼分析：

  1. 定義演算法框架：TestCase 類定義了測試方法執行的演算法框架。這個框架包括測試前的準備 (setUp)、調用實際的測試方法 (runBare) 以及測試後的清理 (tearDown)。
public abstract class TestCase implements Test {
    // 模板方法，定義了測試執行的框架
    public void run(TestResult result) {
        // 測試前的準備
        setUp();

        try {
            // 調用實際的測試方法
            runBare();
        } catch (Throwable e) {
            // 異常處理，可以被子類覆蓋
            result.addError(this, e);
        } finally {
            // 清理資源，確保在任何情況下都執行
            tearDown();
        }
    }

    // 測試前的準備，可以被子類覆蓋
    protected void setUp() throws Exception {
    }

    // 測試方法的執行，可以被子類覆蓋
    protected void runBare() throws Throwable {
        for (int i = 0; i < fCount; i++) {
            runTest();
        }
    }

    // 測試後的清理，可以被子類覆蓋
    protected void tearDown() throws Exception {
    }

    // 執行單個測試方法，通常由 runBare 調用
    public void runTest() throws Throwable {
        // 實際的測試邏輯
    }
}
  1. 允許子類擴展：TestCase 類中的 setUp、runBare 和 tearDown 方法都是 protected，這意味著子類可以覆蓋這些方法來插入自己的邏輯。
public class MyTestCase extends TestCase {
    @Override
    protected void setUp() throws Exception {
        // 子類的初始化邏輯
    }

    @Override
    protected void runBare() throws Throwable {
        // 子類可以自定義測試執行邏輯
        super.runBare();
    }

    @Override
    protected void tearDown() throws Exception {
        // 子類的清理邏輯
    }

    // 實際的測試方法
    public void testMyMethod() {
        // 使用斷言來驗證結果
        assertTrue("測試條件", condition);
    }
}
  1. 執行測試方法：runTest 方法是實際執行測試的地方，通常在 runBare 方法中被調用。TestCase 類維護了一個測試方法數組 fTests，runTest 方法會遍歷這個數組並執行每個測試方法。
public class TestCase {
    // 測試方法數組
    protected final Vector tests = new Vector();

    // 添加測試方法到數組
    public TestCase(String name) {
        tests.addElement(name);
    }

    // 執行單個測試方法
    public void runTest() throws Throwable {
        // 獲取測試方法
        Method runMethod = null;
        try {
            runMethod = this.getClass().getMethod((String) tests.elementAt(testNumber), (Class[]) null);
        } catch (NoSuchMethodException e) {
            fail("Missing test method: " + tests.elementAt(testNumber));
        }
        // 調用測試方法
        runMethod.invoke(this, (Object[]) null);
    }
}

通過模板方法模式，TestCase 類為所有測試用例提供了一個統一的執行模板，確保了測試的一致性和可維護性。同時，它也允許開發者通過覆蓋特定的方法來定製測試的特定步驟，提供了靈活性。這種設計模式在 JUnit 中的成功應用，展示了它在構建大型測試框架中的價值。

3. 建造者模式

在JUnit中，建造者模式主要體現在JUnitCore類的使用上，它允許以一種逐步構建的方式運行測試。JUnitCore類提供了一系列的靜態方法，允許開發者逐步添加測試類和配置選項，最終構建成一個完整的測試運行實例。以下是JUnitCore使用建造者模式的實現過程和源碼分析：

  1. 構建測試運行器：JUnitCore類提供了一個運行測試的入口點。通過main方法或run方法，可以啟動測試。
public class JUnitCore {
    // 運行測試的main方法
    public static void main(String[] args) {
        runMain(new JUnitCore(), args);
    }

    // 運行測試的方法，可以添加測試類和監聽器
    public Result run(Class<?>... classes) {
        return run(Request.classes(Arrays.asList(classes)));
    }

    // 接受請求對象的方法
    public Result run(Request request) {
        // 實際的測試運行邏輯
        return run(request.getRunner());
    }

    // 私有方法，執行測試並返回結果
    private Result run(Runner runner) {
        Result result = new Result();
        RunListener listener = result.createListener();
        notifier.addFirstListener(listener);
        try {
            notifier.fireTestRunStarted(runner.getDescription());
            runner.run(notifier);
            notifier.fireTestRunFinished(result);
        } finally {
            removeListener(listener);
        }
        return result;
    }
}
  1. 創建請求對象：Request類是建造者模式中的建造者類，它提供了方法來逐步添加測試類和其他配置。
public class Request {
    // 靜態方法，用於創建包含測試類的請求
    public static Request classes(Class<?>... classes) {
        return new Request().classes(Arrays.asList(classes));
    }

    // 向請求中添加測試類
    public Request classes(Collection<Class<?>> classes) {
        // 添加測試類邏輯
        return this; // 返回自身，支持鏈式調用
    }

    // 獲取構建好的Runner
    public Runner getRunner() {
        // 創建並返回Runner邏輯
    }
}
  1. 鏈式調用：Request類的方法設計支持鏈式調用，這是建造者模式的一個典型特征。每個方法返回Request對象的引用，允許繼續添加更多的配置。
// 示例使用
Request request = JUnitCore.request()
                          .classes(MyTest.class, AnotherTest.class)
                          // 可以繼續添加其他配置
                          ;
Runner runner = request.getRunner();
Result result = new JUnitCore().run(runner);
  1. 執行測試：一旦通過Request對象構建好了測試配置，就可以通過JUnitCore的run方法來執行測試，並獲取結果。
// 執行測試並獲取結果
Result result = JUnitCore.run(request);

靚仔們，我們可以看到JUnitCore和Request的結合使用體現了建造者模式的精髓。這種模式允許開發者以一種非常靈活和表達性強的方式來構建測試配置，然後再運行它們。建造者模式的使用提高了代碼的可讀性和可維護性，並且使得擴展新的配置選項變得更加容易。

4. 策略模式

策略模式允許在運行時選擇演算法的行為，這在JUnit中體現為不同的Runner實現。每種Runner都定義了執行測試的特定策略，例如，BlockJUnit4ClassRunner是JUnit 4的預設Runner，而JUnitCore允許通過傳遞不同的Runner來改變測試執行的行為。

以下是Runner介面和幾種實現的源碼分析：

  1. 定義策略介面：Runner介面定義了所有測試運行器必須實現的策略方法。run方法接受一個RunNotifier參數，它是JUnit中的一個觀察者，用於通知測試事件。
public interface Runner {
    void run(RunNotifier notifier);
    Description getDescription();
}
  1. 實現具體策略：JUnit 提供了多種Runner實現，每種實現都有其特定的測試執行邏輯。
  • BlockJUnit4ClassRunner是JUnit 4 的預設運行器，它使用註解來識別測試方法，並按順序執行它們。
public class BlockJUnit4ClassRunner extends ParentRunner<TestResult> {
    @Override
    protected void runChild(FrameworkMethod method, RunNotifier notifier) {
        runLeaf(methodBlock(method), description, notifier);
    }

    protected Statement methodBlock(FrameworkMethod method) {
        // 創建一個Statement，可能包含@Before, @After等註解的處理
    }
}
  • Suite是一個Runner實現，它允許將多個測試類組合成一個測試套件。
public class Suite extends ParentRunner<Runner> {
    @Override
    protected void runChild(Runner runner, RunNotifier notifier) {
        runner.run(notifier);
    }
}
  1. 上下文配置：JUnitCore作為上下文，它根據傳入的Runner執行測試。
public class JUnitCore {
    public Result run(Request request) {
        Runner runner = request.getRunner();
        return run(runner);
    }

    private Result run(Runner runner) {
        Result result = new Result();
        RunNotifier notifier = new RunNotifier();
        runner.run(notifier);
        return result;
    }
}
  1. 使用@RunWith註解：開發者可以使用@RunWith註解來指定測試類應該使用的Runner。
@RunWith(Suite.class)
public class MyTestSuite {
    // 測試類組合
}
  1. 自定義Runner：開發者也可以通過實現自己的Runner來改變測試執行的行為。
public class MyCustomRunner extends BlockJUnit4ClassRunner {
    public MyCustomRunner(Class<?> klass) throws InitializationError {
        super(klass);
    }

    @Override
    protected Statement withBefores(FrameworkMethod method, Object target, Statement statement) {
        // 自定義@Before註解的處理
    }
}
  1. 運行自定義Runner：
JUnitCore.runClasses(MyCustomRunner.class, MyTest.class);

通過策略模式，JUnit 允許開發者根據不同的測試需求選擇不同的執行策略，或者通過自定義Runner來擴展測試框架的功能。這種設計提供了高度的靈活性和可擴展性，使得JUnit能夠適應各種複雜的測試場景。

5. 裝飾者模式

裝飾者模式是一種結構型設計模式，它允許用戶在不修改對象自身的基礎上，向一個對象添加新的功能。在JUnit中，裝飾者模式被用於增強測試類的行為，比如通過@RunWith註解來指定使用特定的Runner類來運行測試。

以下是@RunWith註解使用裝飾者模式的實現過程和源碼分析：

  1. 定義組件介面：Runner介面是JUnit中所有測試運行器的組件介面，它定義了運行測試的基本方法。
public interface Runner extends Describable {
    void run(RunNotifier notifier);
    Description getDescription();
}
  1. 創建具體組件：BlockJUnit4ClassRunner是JUnit中一個具體的Runner實現，它提供了執行JUnit 4測試的基本邏輯。
public class BlockJUnit4ClassRunner extends ParentRunner<T> {
    protected BlockJUnit4ClassRunner(Class<?> klass) throws InitializationError {
        super(klass);
    }

    // 實現具體的測試執行邏輯
}
  1. 定義裝飾者抽象類：ParentRunner類是一個裝飾者抽象類，它提供了裝飾Runner的基本結構和預設實現。
public abstract class ParentRunner<T> implements Runner {
    protected Class<?> fTestClass;
    protected Statement classBlock;

    public void run(RunNotifier notifier) {
        // 裝飾並執行測試
    }

    // 其他公共方法和裝飾邏輯
}
  1. 實現具體裝飾者：通過@RunWith註解，JUnit允許開發者指定一個裝飾者Runner來增強測試類的行為。例如，Suite類是一個裝飾者，它可以運行多個測試類。
@RunWith(Suite.class)
@Suite.SuiteClasses({Test1.class, Test2.class})
public class AllTests {
    // 這個類使用SuiteRunner來運行包含的測試類
}
  1. 使用@RunWith註解：開發者通過在測試類上使用@RunWith註解來指定一個裝飾者Runner。
@RunWith(CustomRunner.class)
public class MyTest {
    // 這個測試類將使用CustomRunner來運行
}
  1. 自定義Runner：開發者可以實現自己的Runner來提供額外的功能，如下所示：
public class CustomRunner extends BlockJUnit4ClassRunner {
    public CustomRunner(Class<?> klass) throws InitializationError {
        super(klass);
    }

    @Override
    protected Statement withBefores(FrameworkMethod method, Object target, Statement statement) {
        // 添加@Before註解的處理
        return super.withBefores(method, target, statement);
    }

    @Override
    protected Statement withAfters(FrameworkMethod method, Object target, Statement statement) {
        // 添加@After註解的處理
        return super.withAfters(method, target, statement);
    }
}
  1. 運行時創建裝飾者：在JUnit的運行時，根據@RunWith註解的值，使用反射來實例化對應的Runner裝飾者。
public static Runner getRunner(Class<?> testClass) throws InitializationError {
    RunWith runWith = testClass.getAnnotation(RunWith.class);
    if (runWith == null) {
        return new BlockJUnit4ClassRunner(testClass);
    } else {
        try {
            // 使用反射創建指定的Runner裝飾者
            return (Runner) runWith.value().getConstructor(Class.class).newInstance(testClass);
        } catch (Exception e) {
            throw new InitializationError("Couldn't create runner for class " + testClass, e);
        }
    }
}

通過使用裝飾者模式，JUnit 允許開發者通過@RunWith註解來靈活地為測試類添加額外的行為，而無需修改測試類本身。這種設計提高了代碼的可擴展性和可維護性，同時也允許開發者通過自定義Runner來實現複雜的測試邏輯。

6. 觀察者模式

觀察者模式是一種行為設計模式，它定義了對象之間的一對多依賴關係，當一個對象狀態發生改變時，所有依賴於它的對象都會得到通知並自動更新。在JUnit中，觀察者模式主要應用於測試結果監聽器，以通知測試過程中的各個事件，如測試開始、測試失敗、測試完成等。

以下是JUnit中觀察者模式的實現過程和源碼分析：

  1. 定義觀察者介面：TestListener介面定義了測試過程中需要通知的事件的方法。
public interface TestListener {
    void testAborted(Test test, Throwable t);
    void testAssumptionFailed(Test test, AssumptionViolatedException e);
    void testFailed(Test test, AssertionFailedError e);
    void testFinished(Test test);
    void testIgnored(Test test);
    void testStarted(Test test);
}
  1. 創建主題：RunNotifier類作為主題，維護了一組觀察者列表，並提供了添加、移除觀察者以及通知觀察者的方法。
public class RunNotifier {
    private final List<TestListener> listeners = new ArrayList<TestListener>();

    public void addListener(TestListener listener) {
        listeners.add(listener);
    }

    public void removeListener(TestListener listener) {
        listeners.remove(listener);
    }

    protected void fireTestRunStarted(Description description) {
        for (TestListener listener : listeners) {
            listener.testStarted(null);
        }
    }

    // 其他類似fireTestXXXStarted/Finished等方法
}
  1. 實現具體觀察者：具體的測試結果監聽器實現TestListener介面，根據測試事件執行相應的邏輯。
public class MyTestListener implements TestListener {
    @Override
    public void testStarted(Test test) {
        // 測試開始時的邏輯
    }

    @Override
    public void testFinished(Test test) {
        // 測試結束時的邏輯
    }

    // 實現其他TestListener方法
}
  1. 註冊觀察者：在測試運行前，通過RunNotifier將具體的監聽器添加到觀察者列表中。
RunNotifier notifier = new RunNotifier();
notifier.addListener(new MyTestListener());
  1. 通知觀察者：在測試執行過程中，RunNotifier會調用相應的方法來通知所有註冊的觀察者關於測試事件的信息。
protected void run(Runner runner) {
    // ...
    runner.run(notifier);
    // ...
}
  1. 使用JUnitCore運行測試：JUnitCore類使用RunNotifier來運行測試，並通知註冊的監聽器。
public class JUnitCore {
    public Result run(Request request) {
        Runner runner = request.getRunner();
        return run(runner);
    }

    private Result run(Runner runner) {
        Result result = new Result();
        RunNotifier notifier = new RunNotifier();
        notifier.addListener(result.createListener());
        runner.run(notifier);
        return result;
    }
}
  1. 結果監聽器：Result類本身也是一個觀察者，它實現了TestListener介面，用於收集測試結果。
public class Result implements TestListener {
    public void testRunStarted(Description description) {
        // 測試運行開始時的邏輯
    }

    public void testRunFinished(long elapsedTime) {
        // 測試運行結束時的邏輯
    }

    // 實現其他TestListener方法
}

通過觀察者模式，JUnit 允許開發者自定義測試結果監聽器，以獲取測試過程中的各種事件通知。這種模式提高了測試框架的靈活性和可擴展性，使得開發者可以根據自己的需求來監控和響應測試事件。

7. 依賴註入

依賴註入是一種常見的設計模式，它允許將組件的依賴關係從組件本身中解耦出來，通常通過構造函數、工廠方法或 setter 方法註入。在 JUnit 中，依賴註入主要用於測試領域，特別是與 Mockito 這樣的模擬框架結合使用時，可以方便地註入模擬對象。

以下是 @Mock 和 @InjectMocks 註解使用依賴註入的實現過程和源碼分析：

  1. Mockito 依賴註入註解：

    • @Mock 註解用於創建模擬對象。
    • @InjectMocks 註解用於將模擬對象註入到測試類中。

  2. 使用 @Mock 創建模擬對象：

    • 在測試類中，使用 @Mock 註解的欄位將自動被 Mockito 框架在測試執行前初始化為模擬對象。
public class MyTest {
    @Mock
    private Collaborator mockCollaborator;
    
    // 其他測試方法...
}
  1. 使用 @InjectMocks 進行依賴註入：
    • 當測試類中的對象需要依賴其他模擬對象時，使用 @InjectMocks 註解可以自動註入這些模擬對象。
@RunWith(MockitoJUnitRunner.class)
public class MyTest {
    @Mock
    private Collaborator mockCollaborator;

    @InjectMocks
    private MyClass testClass;
    
    // 測試方法...
}

  1. MockitoJUnitRunner：

    • @RunWith(MockitoJUnitRunner.class) 指定了使用 Mockito 的測試運行器，它負責設置測試環境，包括初始化模擬對象和註入依賴。

  2. Mockito 框架初始化過程：

    • 在測試運行前，Mockito 框架會查找所有使用 @Mock 註解的欄位，並創建相應的模擬對象。
    • 接著，對於使用 @InjectMocks 註解的欄位，Mockito 會進行反射檢查其構造函數和成員變數，使用創建的模擬對象進行依賴註入。

  3. Mockito 註解處理器：

    • Mockito 框架內部使用註解處理器來處理 @Mock 和 @InjectMocks 註解。這些處理器在測試執行前初始化模擬對象，併在必要時註入它們。
public class MockitoAnnotations {
    public static void initMocks(Object testClass) {
        // 查找並初始化 @Mock 註解的欄位
        for (Field field : Reflections.fieldsAnnotatedWith(testClass.getClass(), Mock.class)) {
            field.setAccessible(true);
            try {
                field.set(testClass, MockUtil.createMock(field.getType()));
            } catch (IllegalAccessException e) {
                throw new RuntimeException("Unable to inject @Mock for " + field, e);
            }
        }
        // 查找並處理 @InjectMocks 註解的欄位
        for (Field field : Reflections.fieldsAnnotatedWith(testClass.getClass(), InjectMocks.class)) {
            // 註入邏輯...
        }
    }
}

  1. 測試方法執行：

    • 在測試方法執行期間，如果測試類中的實例調用了被 @Mock 註解的對象的方法，實際上是調用了模擬對象的方法，可以進行行為驗證或返回預設的值。

  2. Mockito 模擬行為：

    • 開發者可以使用 Mockito 提供的 API 來定義模擬對象的行為，例如使用 when().thenReturn() 或 doThrow() 等方法。
when(mockCollaborator.someMethod()).thenReturn("expected value");

通過依賴註入，JUnit 和 Mockito 的結合使用極大地簡化了測試過程中的依賴管理，使得測試代碼更加簡潔和專註於測試邏輯本身。同時，這也提高了測試的可讀性和可維護性。

8. 反射機制

在JUnit中，反射機制是實現動態測試發現和執行的關鍵技術之一。反射允許在運行時檢查類的信息、創建對象、調用方法和訪問欄位，這使得JUnit能夠在不直接引用測試方法的情況下執行它們。以下是使用Java反射API來動態發現和執行測試方法的實現過程和源碼分析：

  1. 獲取類對象：首先，使用Class.forName()方法獲取測試類的Class對象。
Class<?> testClass = Class.forName("com.example.MyTest");
  1. 獲取測試方法列表：通過Class對象，使用Java反射API獲取類中所有聲明的方法。
Method[] methods = testClass.getDeclaredMethods();
  1. 篩選測試方法：遍歷方法列表，篩選出標記為測試方法的Method對象。在JUnit中，這通常是通過@Test註解來標識的。
List<FrameworkMethod> testMethods = new ArrayList<>();
for (Method method : methods) {
    if (method.isAnnotationPresent(Test.class)) {
        testMethods.add(new FrameworkMethod(method));
    }
}
  1. 創建測試方法的封裝對象：JUnit使用FrameworkMethod類來封裝Method對象，提供額外的功能，如處理@Before、@After註解。
public class FrameworkMethod {
    private final Method method;

    public FrameworkMethod(Method method) {
        this.method = method;
    }

    public Object invokeExplosively(Object target, Object... params) throws Throwable {
        try {
            return method.invoke(target, params);
        } catch (IllegalAccessException | InvocationTargetException e) {
            throw new Exception("Failed to invoke " + method, e.getCause());
        }
    }
}
  1. 調用測試方法：使用FrameworkMethod的invokeExplosively()方法，在指定的測試實例上調用測試方法。
public class BlockJUnit4ClassRunner extends ParentRunner<MyClass> {
    @Override
    protected void runChild(FrameworkMethod method, RunNotifier notifier) {
        runLeaf(new Statement() {
            @Override
            public void evaluate() throws Throwable {
                Object target = new MyClass();
                method.invokeExplosively(target);
            }
        }, methodBlock(method), notifier);
    }
}

  1. 處理測試方法的執行：在invokeExplosively()方法中，使用Method對象的invoke()方法來執行測試方法。這個方法能夠處理方法的訪問許可權，並調用實際的測試邏輯。

  2. 異常處理：在執行測試方法時，可能會拋出異常。JUnit需要捕獲這些異常，並適當地處理它們，例如將測試失敗通知給RunNotifier。

  3. 整合到測試運行器：將上述過程整合到JUnit的測試運行器中，如BlockJUnit4ClassRunner，它負責創建測試實例、調用測試方法，並處理測試結果。

通過使用Java反射API，JUnit能夠以一種非常靈活和動態的方式來執行測試方法。這種機制不僅提高了JUnit框架的通用性和可擴展性，而且允許開發者在不修改測試類代碼的情況下，通過配置和註解來控制測試的行為。反射機制是JUnit強大功能的一個重要支柱。

9. 異常處理

在JUnit中，異常處理是一個精細的過程，確保了測試執行的穩定性和結果的準確性。JUnit區分了預期的異常（如測試中顯式檢查的異常）和未預期的異常（如錯誤或未捕獲的異常），並相應地報告這些異常。以下是JUnit中異常處理的實現過程和源碼分析：

  1. 測試方法執行：在測試方法執行時，JUnit會捕獲所有拋出的異常。
public void runBare() throws Throwable {
    Throwable exception = null;
    try {
        method.invoke(target);
    } catch (InvocationTargetException e) {
        exception = e.getCause();
    } catch (IllegalAccessException e) {
        exception = e;
    } catch (IllegalArgumentException e) {
        exception = e;
    } catch (SecurityException e) {
        exception = e;
    }
    if (exception != null) {
        runAfters();
        throw exception;
    }
}
  1. 預期異常的處理：使用@Test(expected = Exception.class)註解可以指定測試方法預期拋出的異常類型。如果實際拋出的異常與預期不符，JUnit會報告測試失敗。
@Test(expected = SpecificException.class)
public void testMethod() {
    // 測試邏輯，預期拋出 SpecificException
}
  1. 斷言異常：Assert類提供了assertThrows方法，允許在測試中顯式檢查方法是否拋出了預期的異常。
public static <T extends Throwable> T assertThrows(
    Class<T> expectedThrowable, Executable executable, String message) {
    try {
        executable.execute();
        fail(message);
    } catch (Throwable actualException) {
        if (!expectedThrowable.isInstance(actualException)) {
            throw new AssertionFailedError(
                "Expected " + expectedThrowable.getName() + " but got " + actualException.getClass().getName());
        }
        @SuppressWarnings("unchecked")
        T result = (T) actualException;
        return result;
    }
}

  1. 異常的分類：JUnit將異常分為兩種類型：AssertionError和Throwable。AssertionError通常表示測試失敗，而Throwable可能表示測試中的嚴重錯誤。

  2. 異常的報告：在捕獲異常後，JUnit會將異常信息報告給RunNotifier，以便進行適當的處理。

protected void runChild(FrameworkMethod method, RunNotifier notifier) {
    runLeaf(new Statement() {
        @Override
        public void evaluate() throws Throwable {
            try {
                method.invokeExplosively(testInstance);
            } catch (Throwable e) {
                notifier.fireTestFailure(new Failure(method, e));
            }
        }
    }, describeChild(method), notifier);
}
  1. 異常的監聽：RunNotifier監聽器可以捕獲並處理測試過程中拋出的異常，例如記錄失敗或向用戶報告錯誤。
public void addListener(TestListener listener) {
    listeners.add(listener);
}

// 在測試執行過程中調用
notifier.fireTestFailure(new Failure(method, e));

  1. 自定義異常處理：開發者可以通過實現自定義的TestListener來捕獲和處理測試過程中的異常。

  2. 異常的傳播：在某些情況下，JUnit允許異常向上傳播，使得測試框架或IDE能夠捕獲並顯示給用戶。

通過精細的異常處理，JUnit確保了測試的準確性和可靠性，同時提供了靈活的錯誤報告機制。這使得開發者能夠快速定位和解決問題，提高了開發和測試的效率。

10. 解耦合

在JUnit中，解耦合是通過將測試執行的不同方面分離成獨立的組件來實現的，從而提高了代碼的可維護性和可擴展性。以下是解耦合實現過程的詳細分析：

  1. 測試執行器（Runner）：Runner介面定義了執行測試的方法，每個具體的Runner實現負責運行測試用例的邏輯。
public interface Runner {
    void run(RunNotifier notifier);
    Description getDescription();
}
  1. 測試監聽器（RunListener）：RunListener介面定義了測試過程中的事件回調方法，用於監聽測試的開始、成功、失敗和結束等事件。
public interface RunListener {
    void testRunStarted(Description description);
    void testRunFinished(Result result);
    void testStarted(Description description);
    void testFinished(Description description);
    // 其他事件回調...
}
  1. 測試結果（Result）：Result類實現了RunListener介面，用於收集和存儲測試執行的結果。
public class Result implements RunListener {
    private List<Failure> failures = new ArrayList<>();

    @Override
    public void testRunFinished(Result result) {
        // 收集測試運行結果
    }

    @Override
    public void testFailure(Failure failure) {
        // 收集測試失敗信息
        failures.add(failure);
    }

    // 其他RunListener方法實現...
}

  1. 職責分離：Runner負責執行測試邏輯，RunListener負責監聽測試事件，而Result負責收集測試結果。這三者通過介面和回調機制相互協作，但各自獨立實現。

  2. 使用RunNotifier協調：RunNotifier類作為協調者，維護了RunListener的註冊和事件分發。

public class RunNotifier {
    private final List<RunListener> listeners = new ArrayList<>();

    public void addListener(RunListener listener) {
        listeners.add(listener);
    }

    public void fireTestRunStarted(Description description) {
        for (RunListener listener : listeners) {
            listener.testRunStarted(description);
        }
    }

    // 其他事件分發方法...
}
  1. 測試執行流程：在測試執行時，Runner會創建一個RunNotifier實例，然後執行測試，併在適當的時候調用RunNotifier的事件分發方法。
public class BlockJUnit4ClassRunner extends ParentRunner {
    @Override
    protected void runChild(FrameworkMethod method, RunNotifier notifier) {
        RunBefores runBefores = new RunBefores(noTestsYet, method, null);
        Statement statement = new RunAfters(runBefores, method, null);
        statement.evaluate();
    }

    @Override
    public void run(RunNotifier notifier) {
        // 初始化測試運行
        Description description = getDescription();
        notifier.fireTestRunStarted(description);
        try {
            // 執行測試
            runChildren(makeTestRunNotifier(notifier, description));
        } finally {
            // 測試運行結束
            notifier.fireTestRunFinished(result);
        }
    }
}

  1. 結果收集和報告：測試完成後，Result對象會包含所有測試的結果，可以被用來生成測試報告或進行其他後續處理。

  2. 解耦合的優勢：通過將測試執行、監聽和結果收集分離，JUnit允許開發者自定義測試執行流程（通過自定義Runner）、添加自定義監聽器（通過實現RunListener介面）以及處理測試結果（通過操作Result對象）。

這種解耦合的設計使得JUnit非常靈活，易於擴展，同時也使得測試代碼更加清晰和易於理解。開發者可以根據需要替換或擴展框架的任何部分，而不影響其他部分的功能。

11. 可擴展性

JUnit的可擴展性體現在多個方面，包括自定義Runner、TestRule和斷言（Assertion）方法。以下是這些可擴展性點的實現過程和源碼分析：

自定義 Runner

自定義Runner允許開發者定義自己的測試運行邏輯。以下是創建自定義Runner的步驟：

  1. 實現Runner介面：創建一個類實現Runner介面，並實現run方法和getDescription方法。
public class CustomRunner extends Runner {
    private final Class<?> testClass;

    public CustomRunner(Class<?> testClass) throws InitializationError {
        this.testClass = testClass;
    }

    @Override
    public Description getDescription() {
        // 返回測試描述
    }

    @Override
    public void run(RunNotifier notifier) {
        // 自定義測試運行邏輯
    }
}
  1. 使用@RunWith註解：在測試類上使用@RunWith註解來指定使用自定義的Runner。
@RunWith(CustomRunner.class)
public class MyTests {
    // 測試方法...
}

自定義 TestRule

TestRule介面允許開發者插入測試方法執行前後的邏輯。以下是創建自定義TestRule的步驟：

  1. 實現TestRule介面：創建一個類實現TestRule介面。
public class CustomTestRule implements TestRule {
    @Override
    public Statement apply(Statement base, FrameworkMethod method, Object target) {
        // 返回一個Statement，包裝原始的測試邏輯
    }
}
  1. 使用@Rule註解：在測試類或方法上使用@Rule註解來指定使用自定義的TestRule。
public class MyTests {
    @Rule
    public CustomTestRule customTestRule = new CustomTestRule();

    // 測試方法...
}

自定義 Assertion 方法

JUnit提供了一個Assert類，包含許多斷言方法。開發者也可以添加自己的斷言方法：

  1. 擴展Assert類：創建一個工具類，添加自定義的靜態方法。
public class CustomAssertions {
    public static void assertEquals(String message, int expected, int actual) {
        if (expected != actual) {
            throw new AssertionFailedError(message);
        }
    }
}
  1. 使用自定義斷言：在測試方法中調用自定義的斷言方法。
public void testCustomAssertion() {
    CustomAssertions.assertEquals("Values should be equal", 1, 2);
}

源碼分析

以下是使用自定義Runner、TestRule和斷言方法的示例：

// 自定義Runner
public class CustomRunner extends Runner {
    public CustomRunner(Class<?> klass) throws InitializationError {
        // 初始化邏輯
    }

    @Override
    public Description getDescription() {
        // 返回測試的描述信息
    }

    @Override
    public void run(RunNotifier notifier) {
        // 自定義測試執行邏輯，包括調用測試方法和處理測試結果
    }
}

// 自定義TestRule
public class CustomTestRule implements TestRule {
    @Override
    public Statement apply(Statement base, FrameworkMethod method, Object target) {
        // 包裝原始的測試邏輯，可以在測試前後執行額外的操作
        return new Statement() {
            @Override
            public void evaluate() throws Throwable {
                // 測試前的邏輯
                base.evaluate();
                // 測試後的邏輯
            }
        };
    }
}

// 使用自定義Runner和TestRule的測試類
@RunWith(CustomRunner.class)
public class MyTests {
    @Rule
    public CustomTestRule customTestRule = new CustomTestRule();

    @Test
    public void myTest() {
        // 測試邏輯，使用自定義斷言
        CustomAssertions.assertEquals("Expected and actual values should match", 1, 1);
    }
}

通過這些自定義擴展，JUnit允許開發者根據特定需求調整測試行為，增強測試框架的功能，實現高度定製化的測試流程。這種可擴展性是JUnit強大適應性的關鍵因素之一。

12. 參數化測試

參數化測試是JUnit提供的一項功能，它允許為單個測試方法提供多種輸入參數，從而用一個測試方法覆蓋多種測試場景。以下是參數化測試的實現過程和源碼分析：

  1. 使用@Parameterized註解：首先，在測試類上使用@RunWith(Parameterized.class)來指定使用參數化測試的Runner。
@RunWith(Parameterized.class)
public class MyParameterizedTests {
    // 測試方法的參數
    private final int input;
    private final int expectedResult;

    // 構造函數，用於接收參數
    public MyParameterizedTests(int input, int expectedResult) {
        this.input = input;
        this.expectedResult = expectedResult;
    }

    // 測試方法
    @Test
    public void testWithParameters() {
        // 使用參數進行測試
        assertEquals(expectedResult, someMethod(input));
    }

    // 獲取參數來源
    @Parameters
    public static Collection<Object[]> data() {
        return Arrays.asList(new Object[][] {
            { 1, 2 },
            { 2, 4 },
            { 3, 6 }
        });
    }
}
  1. 定義測試參數：使用@Parameters註解的方法來定義測試參數。這個方法需要返回一個Collection，其中包含參數數組的列表。
@Parameters
public static Collection<Object[]> parameters() {
    return Arrays.asList(new Object[][] {
        // 參數列表
    });
}
  1. 構造函數註入：參數化測試框架會通過構造函數將參數註入到測試實例中。
public MyParameterizedTests(int param1, String param2) {
    // 使用參數初始化測試用例
}

  1. 參數化測試的執行：JUnit框架會為@Parameters方法中定義的每一組參數創建測試類的實例，並執行測試方法。

  2. 自定義參數源：除了使用@Parameters註解的方法外，還可以使用Parameterized.ParametersRunnerFactory註解來指定自定義的參數源。

@RunWith(value = Parameterized.class, runnerFactory = MyParametersRunnerFactory.class)
public class MyParameterizedTests {
    // 測試方法和參數...
}

public class MyParametersRunnerFactory implements ParametersRunnerFactory {
    @Override
    public Runner createRunnerForTestWithParameters(TestWithParameters test) {
        // 返回自定義的參數化運行器
    }
}
  1. 使用Arguments輔助類：在JUnit 4.12中，可以使用Arguments類來簡化參數的創建。
@Parameters
public static Collection<Object[]> data() {
    return Arrays.asList(
        Arguments.arguments(1, 2),
        Arguments.arguments(2, 4),
        Arguments.arguments(3, 6)
    );
}
  1. 源碼分析：Parameterized類是實現參數化測試的核心。它使用ParametersRunnerFactory來創建Runner，然後為每組參數執行測試方法。
public class Parameterized {
    public static class ParametersRunnerFactory implements RunnerFactory {
        @Override
        public Runner create(Description description) {
            return new BlockJUnit4ClassRunner(description.getTestClass()) {
                @Override
                protected List<Runner> getChildren() {
                    // 獲取參數併為每組參數創建Runner
                }
            };
        }
    }
    // 其他實現...
}

通過參數化測試，JUnit允許開發者編寫更靈活、更全面的測試用例，同時保持測試代碼的簡潔性。這種方法特別適合於需要多種輸入組合來驗證邏輯正確性的場景。

13. 代碼的模塊化

代碼的模塊化是軟體設計中的一種重要實踐，它將程式分解為獨立的、可重用的模塊，每個模塊負責一部分特定的功能。在JUnit框架中，模塊化設計體現在其清晰的包結構和類的設計上。以下是JUnit中模塊化實現的過程和源碼分析：

  1. 包結構：JUnit的源碼按照功能劃分為不同的包（packages），每個包包含一組相關的類。
// 核心包，包含JUnit的基礎類和介面
org.junit

// 斷言包，提供斷言方法
org.junit.Assert

// 運行器包，負責測試套件的運行和管理
org.junit.runner

// 規則包，提供測試規則，如測試隔離和初始化
org.junit.rules
  1. 介面定義：JUnit使用介面（如Test、Runner、TestRule）定義模塊的契約，確保模塊間的松耦合。
public interface Test {
    void run(TestResult result);
}

public interface Runner {
    void run(RunNotifier notifier);
    Description getDescription();
}
  1. 抽象類：使用抽象類（如Assert、Runner、TestWatcher）為模塊提供共用的實現，同時保留擴展的靈活性。
public abstract class Assert {
    // 斷言方法的預設實現
}

public abstract class Runner implements Describable {
    // 測試運行器的預設實現
}
  1. 具體實現：為每個抽象類或介面提供具體的實現，這些實現類可以在不同的測試場景中重用。
public class TestCase extends Assert implements Test {
    // 測試用例的具體實現
}

public class BlockJUnit4ClassRunner extends ParentRunner {
    // 測試類的運行器實現
}

  1. 依賴倒置：通過依賴介面而非具體實現，JUnit的模塊可以在不修改其他模塊的情況下進行擴展或替換。

  2. 服務提供者介面（SPI）：JUnit使用服務提供者介面來發現和載入擴展模塊，如測試規則（TestRule）。

public interface TestRule {
    Statement apply(Statement base, Description description);
}
  1. 模塊化測試執行：JUnit允許開發者通過@RunWith註解指定自定義的Runner，這允許對測試執行過程進行模塊化定製。
@RunWith(CustomRunner.class)
public class MyTests {
    // ...
}
  1. 參數化測試模塊：參數化測試通過@Parameters註解和Parameterized類實現模塊化，允許為測試方法提供不同的輸入參數集。
@RunWith(Parameterized.class)
public class MyParameterizedTests {
    @Parameters
    public static Collection<Object[]> data() {
        // 提供參數集
    }
}
  1. 解耦的事件監聽：RunNotifier和RunListener介面的使用使得測試事件的監聽和處理可以獨立於測試執行邏輯。
public class RunNotifier {
    public void addListener(RunListener listener);
    // ...
}
  1. 測試結果的模塊化處理：Result類實現了RunListener介面，負責收集和報告測試結果，與測試執行邏輯解耦。

通過這種模塊化設計，JUnit提供了一個靈活、可擴展的測試框架，允許開發者根據自己的需求添加自定義的行為和擴展功能。這種設計不僅提高了代碼的可維護性，也方便了重用和測試過程的定製。

最後

以上就是V哥在 JUnit 框架源碼學習時總結的13個非常值得學習的點，希望也可以幫助到你提升編碼的功力，歡迎關註威哥愛編程，一起學習框架源碼，提升編程技巧，我是 V哥，愛 編程，一輩子。


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 實習第一天，不小心透露了，我是拆遷戶
    2018年6月，大三暑假進行時 上班之前，我提前跟家裡人打過招呼了。 我說我已經拿到了實習的offer，明天就過去上班，離家裡很近，月薪3500，我騎自行車過去就行。 家裡人就說挺好的，讓我騎個電瓶車，這樣會快點，囑咐我好好乾。 這是我第一次正式上班，我還覺得挺神奇的，沒想到我都要上班了。 大學以前 ...
  • P8037 [COCI2015-2016#7] Prokletnik
    二維差分 為什麼我為OI淚目？因為我菜得離譜...... 引入 一維差分用來O(1)修改區間，配合上一維首碼和就是O(N)的查詢區間和。 差分為首碼和的逆運算。 二維差分同理。 接下來這道題就用二維差分來解決。 \(例題：地毯>>\) 地毯 題目描述 在 \(n\times n\) 的格子上有 \( ...
  • Java微信公眾號推送模版消息的方法示例
    本文詳細介紹瞭如何使用Java結合微信官方提供的API來實現模板消息的推送，該方法通過獲取access_token、組裝模板消息數據、發送請求四個步驟微信公眾號推送模版消息。 ...
  • Python 開發環境的準備以及一些常用類庫模塊的安裝
    在學習和開發Python的時候，第一步的工作就是先準備好開發環境，包括相關常用的插件，以及一些輔助工具，這樣我們在後續的開發工作中，才能做到事半功倍。下麵介紹一些Python 開發環境的準備以及一些常用類庫模塊的安裝和使用的經驗總結，供大家參考瞭解。 ...
  • Linux C++ 開發3 - 你寫的Hello world經過哪些過程才被電腦理解和執行？
    1. C/C++的編譯過程 1.1. 預處理 1.2. 編譯 1.3. 彙編 1.3.1. 彙編過程 1.3.2. 目標文件 1.4. 鏈接 2. 編譯過程示例 2.1. 源代碼 2.2. 逐步編譯程式 2.2.1. 編譯指令 2.2.2. 鏈接報錯問題 2.3. 單步編譯 3. gcc/g++與g ...
  • leetcode刷題筆記8.5-8.9
    刷題筆記8.5-8.9 刷題順序依照labuladong演算法小抄 兩數之和(8.5) 初始化數組： int[] num = new int<length>; int[] num = {1,2,3,4}; 其中數組名代表指針變數，故不可以直接將數組名a賦值給數組名b 錯誤的複製：int[] b = a ...
  • k8s技術總結（一）
    正文 周五寫了一整天學海計劃，周六跟了一天的編曲教程，今天則是把第三章剩下的教程跟完。最後，迴旋曲寫是寫出來了，就是把自己聽笑了。寫得實在太爛了。 昨天晚上買了回來的機票。9 月 10 號一早。該說不說機票是真的貴啊…… 同時，我發現我過去的機票，執飛飛機是波音 737-800…… 我怎麼才發現。我 ...
  • NetCDF 文件批量轉柵格並導出柵格各波段
    我們可以通過 ArcGIS Pro 腳本將 NetCDF 文件批量轉為柵格文件並將其各個波段分別導出為 tif 文件，本文將對該腳本代碼及其在 ArcGIS Pro 中的配置過程進行介紹。 ...
一周排行
    -Advertisement-
    Play Games
  • WPF 已知問題 監聽 WMI 事件導致觸摸失效
    示例項目結構 在 Visual Studio 中創建一個 WinForms 應用程式後，項目結構如下所示： MyWinFormsApp/ │ ├───Properties/ │ └───Settings.settings │ ├───bin/ │ ├───Debug/ │ └───Release/ ...
  • [STAThread]特性
    [STAThread] 特性用於需要與 COM 組件交互的應用程式，尤其是依賴單線程模型（如 Windows Forms 應用程式）的組件。在 STA 模式下，線程擁有自己的消息迴圈，這對於處理用戶界面和某些 COM 組件是必要的。 [STAThread] static void Main(stri ...
  • UWP WinUI3 傳入 AddHandler 的 RoutedEventHandler 類型與事件所需不匹配將拋出參數異常
    在WinForm中使用全局異常捕獲處理 在WinForm應用程式中，全局異常捕獲是確保程式穩定性的關鍵。通過在Program類的Main方法中設置全局異常處理，可以有效地捕獲並處理未預見的異常，從而避免程式崩潰。 註冊全局異常事件 [STAThread] static void Main() { / ...
  • .NET 多版本 WinForm 開源控制項庫 SunnyUI
    前言 給大家推薦一款開源的 Winform 控制項庫，可以幫助我們開發更加美觀、漂亮的 WinForm 界面。 項目介紹 SunnyUI.NET 是一個基於 .NET Framework 4.0+、.NET 6、.NET 7 和 .NET 8 的 WinForm 開源控制項庫，同時也提供了工具類庫、擴展 ...
  • .net core8 使用Swagger（附當前源碼）
    說明 該文章是屬於OverallAuth2.0系列文章，每周更新一篇該系列文章（從0到1完成系統開發）。 該系統文章，我會儘量說的非常詳細，做到不管新手、老手都能看懂。 說明：OverallAuth2.0 是一個簡單、易懂、功能強大的許可權+可視化流程管理系統。 有興趣的朋友，請關註我吧(*^▽^*) ...
  • WPF 什麼時候 VisualTreeHelper.GetDescendantBounds 將返回無窮大
    一、下載安裝 1.下載git 必須先下載並安裝git，再TortoiseGit下載安裝 git安裝參考教程：https://blog.csdn.net/mukes/article/details/115693833 2.TortoiseGit下載與安裝 TortoiseGit，Git客戶端，32/6 ...
  • C# 開源教程帶你輕鬆掌握數據結構與演算法
    前言 在項目開發過程中，理解數據結構和演算法如同掌握蓋房子的秘訣。演算法不僅能幫助我們編寫高效、優質的代碼，還能解決項目中遇到的各種難題。 給大家推薦一個支持C#的開源免費、新手友好的數據結構與演算法入門教程：Hello演算法。 項目介紹 《Hello Algo》是一本開源免費、新手友好的數據結構與演算法入門 ...
  • 第22篇 生成proto文件bat腳本
    1.生成單個Proto.bat內容 @rem Copyright 2016, Google Inc. @rem All rights reserved. @rem @rem Redistribution and use in source and binary forms, with or with ...
  • 記一次 .NET某上位機視覺程式 卡死分析
    一：背景 1. 講故事 前段時間有位朋友找到我，說他的窗體程式在客戶這邊出現了卡死，讓我幫忙看下怎麼回事？dump也生成了，既然有dump了那就上 windbg 分析吧。 二：WinDbg 分析 1. 為什麼會卡死 窗體程式的卡死，入口門檻很低，後續往下分析就不一定了，不管怎麼說先用 !clrsta ...
  • 醫學DICOM文件與PACS系統進行數據傳輸
    前言 人工智慧時代，人臉識別技術已成為安全驗證、身份識別和用戶交互的關鍵工具。 給大家推薦一款.NET 開源提供了強大的人臉識別 API，工具不僅易於集成，還具備高效處理能力。 本文將介紹一款如何利用這些API，為我們的項目添加智能識別的亮點。 項目介紹 GitHub 上擁有 1.2k 星標的 C# ...
所有分類