From 6fcd94f813ae09aae33b1222bc1471b8e0bc1cff Mon Sep 17 00:00:00 2001
From: Hau Nguyen <hauvipapro@gmail.com>
Date: Wed, 24 Jan 2024 11:38:03 +0700
Subject: [PATCH] feat: draft testing

---
 docs/2024-01-20-backend-thinking.html | 46 ++++++++++++++++++++-------
 posts/2024-01-20-backend-thinking.md  | 23 ++++++++------
 2 files changed, 48 insertions(+), 21 deletions(-)

diff --git a/docs/2024-01-20-backend-thinking.html b/docs/2024-01-20-backend-thinking.html
index d74b89e..166e780 100644
--- a/docs/2024-01-20-backend-thinking.html
+++ b/docs/2024-01-20-backend-thinking.html
@@ -294,13 +294,13 @@
     <p>All of these above are industry standard.</p>
     <h3>
       <a
-        id="user-content-write-code-to-delete"
+        id="user-content-write-code-that-is-easy-delete"
         class="anchor"
         aria-hidden="true"
         tabindex="-1"
-        href="#write-code-to-delete"
+        href="#write-code-that-is-easy-delete"
         ><span aria-hidden="true" class="octicon octicon-link"></span></a
-      >Write code to delete
+      >Write code that is easy delete
     </h3>
     <p>
       The way business moving is fast, so a feature is maybe implemented today,
@@ -353,17 +353,17 @@
     </p>
     <h3>
       <a
-        id="user-content-write-code-to-test"
+        id="user-content-write-code-that-is-easy-to-test"
         class="anchor"
         aria-hidden="true"
         tabindex="-1"
-        href="#write-code-to-test"
+        href="#write-code-that-is-easy-to-test"
         ><span aria-hidden="true" class="octicon octicon-link"></span></a
-      >Write code to test
+      >Write code that is easy to test
     </h3>
     <p>
       Test is not a way to find bug, test is a way for us to make sure what we
-      code is actually what we think.
+      code is actually what we think/expect.
     </p>
     <p>
       Best case scenerio is test with real dependencies (real servives, real
@@ -374,12 +374,34 @@
       The easier way is to use mocks. Mock all dependencies to test all possible
       edge cases you can think of.
     </p>
+    <ul>
+      <li>
+        Unit tests is the standard (ZaloPay currently requires 90% test
+        coverage).
+        <ul>
+          <li>
+            Easy to test small to medium function which have simple rules,
+            likely single purpose with table testing technique.
+          </li>
+          <li>
+            For big, complex function, the strategy testing goes from happy case
+            to each single edge case, each single if else path,... try to cover
+            as much as you can.
+          </li>
+        </ul>
+      </li>
+      <li>
+        Integration tests in 2 ways:
+        <ul>
+          <li>
+            Locally, which require to run in your computer with fully set up
+            dependencies, is hard to set up.
+          </li>
+          <li>Remotely, use DEV env to test APIs.</li>
+        </ul>
+      </li>
+    </ul>
     <p>TODO: Show example</p>
-    <p>
-      Same solution is to keep our code loosely coupled as much as possible.
-    </p>
-    <p>Each function/ should be contained.</p>
-    <p>Not all</p>
     <h3>
       <a
         id="user-content-references-1"
diff --git a/posts/2024-01-20-backend-thinking.md b/posts/2024-01-20-backend-thinking.md
index 236ffd2..97971cd 100644
--- a/posts/2024-01-20-backend-thinking.md
+++ b/posts/2024-01-20-backend-thinking.md
@@ -129,7 +129,7 @@ and when to not.
 
 All of these above are industry standard.
 
-### Write code to delete
+### Write code that is easy delete
 
 The way business moving is fast, so a feature is maybe implemented today, but
 gets thrown out of window tomorrow (Like A/B testing, one of them is chosen, the
@@ -167,10 +167,10 @@ like a module (think like lego) which can be plug and play right away.
 And when we do not need send noti anymore, we can delete whole of it which
 includes all providers and still not affecting main flow.
 
-### Write code to test
+### Write code that is easy to test
 
 Test is not a way to find bug, test is a way for us to make sure what we code is
-actually what we think.
+actually what we think/expect.
 
 Best case scenerio is test with real dependencies (real servives, real Redis,
 real MySQL, real Kafka, ...). But it's not easy way to setup yourself.
@@ -178,14 +178,19 @@ real MySQL, real Kafka, ...). But it's not easy way to setup yourself.
 The easier way is to use mocks. Mock all dependencies to test all possible edge
 cases you can think of.
 
+- Unit tests is the standard (ZaloPay currently requires 90% test coverage).
+  - Easy to test small to medium function which have simple rules, likely single
+    purpose with table testing technique.
+  - For big, complex function, the strategy testing goes from happy case to each
+    single edge case, each single if else path,... try to cover as much as you
+    can.
+- Integration tests in 2 ways:
+  - Locally, which require to run in your computer with fully set up
+    dependencies, is hard to set up.
+  - Remotely, use DEV env to test APIs.
+
 TODO: Show example
 
-Same solution is to keep our code loosely coupled as much as possible.
-
-Each function/ should be contained.
-
-Not all
-
 ### References
 
 - [Write code that is easy to delete, not easy to extend.](https://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to)