From 5425518b6e72b0e69ae52970e9dfe31cddc1371f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E6=AE=B5=E6=B5=A9=E6=B5=A9?=
 <49123491+haohaoya@users.noreply.github.com>
Date: Fri, 25 Apr 2025 15:17:25 +0800
Subject: [PATCH] fix: typo

---
 docs/README.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/README.md b/docs/README.md
index 90bfecf..f66a613 100644
--- a/docs/README.md
+++ b/docs/README.md
@@ -377,7 +377,7 @@ Cons:
 You can using following order to decide how to test your code:
 
 1. DI framework is naturally easy to unit test by inject all things through constructor.
-2. Using mockk or other mocking framework to mock the dependency.
+2. Using MockK or other mocking framework to mock the dependency.
 
 Actually, we have implemented a unit test framework for Knit, which is based on run bytecode transformation at runtime, but it is very time costly because it needs to scan all runtime classpath to find all components, so we are still focused on how to optimize it and not published it yet.