diff --git a/docs/2022-12-25-go-test-asap.html b/docs/2022-12-25-go-test-asap.html index 2715f30..c5c8cbc 100644 --- a/docs/2022-12-25-go-test-asap.html +++ b/docs/2022-12-25-go-test-asap.html @@ -1,4 +1,4 @@ -Index

Speed up writing Go test ASAP

Imagine your project currently have 0% unit test code coverage.
And your boss keep pushing it to 80% or even 90%?
What do you do?
Give up?

What if I tell you there is a way?
Not entirely cheating but ... you know, there is always trade off.

If your purpose is to test carefully all path, check if all return is correctly.
Sadly this post is not for you, I guess.
If you only want good number on test coverage, with minimum effort as possible, I hope this will show you some idea you can use :)

In my opinion, unit test is not that important (like must must have).
It's just make sure your code is running excatly as you intent it to be.
If you don't think about edge case before, unit test won't help you.

First, rewrite the impossible (to test) out

When I learn to programming, I encounter very interesting idea, which become mainly my mindset when I dev later.
I don't recall it clearly, kinda like: "Don't just fix bugs, rewrite so that kind of bugs will not appear later".
So in our context, there is some thing we hardly or can not write test in Go.
My solution is don't use that thing.

In my experience, I can list a few things here:

Let the fun (writing test) begin

If you code Go long enough, you know table driven tests and how is that so useful.
You set up test data, then you test.
Somewhere in the future, you change the func, then you need to update test data, then you good!

In simple case, your func only have 2 or 3 inputs table drive tests still looking good.
But real world is ugly (maybe not, idk I'm just too young in this industry :). Your func can have 5 or 10 inputs, also your func call many third party services.

Imagine having below func to upload image:

type service struct {
+Index
Speed up writing Go test ASAP
Imagine your project currently have 0% unit test code coverage.
And your boss keep pushing it to 80% or even 90%?
What do you do?
Give up?
What if I tell you there is a way?
Not entirely cheating but ... you know, there is always trade off.
If your purpose is to test carefully all path, check if all return is correctly.
Sadly this post is not for you, I guess.
If you only want good number on test coverage, with minimum effort as possible, I hope this will show you some idea you can use :)
In my opinion, unit test is not that important (like must must have).
It's just make sure your code is running excatly as you intent it to be.
If you don't think about edge case before, unit test won't help you.
First, rewrite the impossible (to test) out
When I learn programming, I encounter very interesting idea, which become mainly my mindset when I dev later.
I don't recall it clearly, kinda like: "Don't just fix bugs, rewrite it so that kind of bugs will not appear again".
So in our context, there is some thing we hardly or can not write test in Go.
My suggestion is don't use that thing.
In my experience, I can list a few things here:
Let the fun (writing test) begin
If you code Go long enough, you know table driven tests and how is that so useful.
You set up test data, then you test.
Somewhere in the future, you change the func, then you need to update test data, then you good!
In simple case, your func only have 2 or 3 inputs table drive tests still looking good.
But real world is ugly (maybe not, idk I'm just too young in this industry :). Your func can have 5 or 10 inputs, also your func call many third party services.
Imagine having below func to upload image:
type service struct {
     db DB
     redis Redis
     minio MinIO
diff --git a/posts/2022-12-25-go-test-asap.md b/posts/2022-12-25-go-test-asap.md
index d4ae270..63f5c94 100644
--- a/posts/2022-12-25-go-test-asap.md
+++ b/posts/2022-12-25-go-test-asap.md
@@ -18,10 +18,10 @@ If you don't think about edge case before, unit test won't help you.
 
 ## First, rewrite the impossible (to test) out
 
-When I learn to programming, I encounter very interesting idea, which become mainly my mindset when I dev later.
-I don't recall it clearly, kinda like: "Don't just fix bugs, rewrite so that kind of bugs will not appear later".
+When I learn programming, I encounter very interesting idea, which become mainly my mindset when I dev later.
+I don't recall it clearly, kinda like: "Don't just fix bugs, rewrite it so that kind of bugs will not appear again".
 So in our context, there is some thing we hardly or can not write test in Go.
-My solution is don't use that thing.
+My suggestion is don't use that thing.
 
 In my experience, I can list a few things here: