How to Write a Good Test

My Notes about tests

Test functions interact with DB

To test all CRUD operations thoroughly, it is important to create a new testing account first. This ensures that all tests are independent of each other

• First, Connect the DB in the test main file. Eg. main_test.go , index.test.js (?)
• Generate a input for the function
• Check test cases

Check list of test cases:

1. The returned value from DB (by the function) should not be err
2. Returned value should not be empty object
3. The argument and the returned value should be matched
4. The returned value should contain automatically generated value by DB (eg. ID)

Test case of transactions should be similar

But be careful about concurrency handling (in Golang)

Test APIs

How to mock DB?

1. Store data in memory

type Store interface{
  GetAccount(id int64) (Account, error)
}

type MemStore struct {
  data map[int64]Account
}

func (store * MemStore) GetAccount(id int64) (Account, error) {
  return store.data[id], nil
}

2. Use DB stubs

• Eg. gomock

Write API tests

• Create a tested instance (eg account)
• Init mock store

func TestGetAccountAPI(t *testing.T) {
  ctrl := gomock.NewController(t)
  defer ctrl.Finish()

  mockStore := mockdb.NewMockStore(ctrl)
}

• Build stubs
• Create test server and send requests + use recorder to mock response
• check response

Test cases:

1. “OK” (Happy case)
2. Not Found
3. BadRequest
4. InternalServerError
5. No auth
6. Unauthorized User

• 先有好的設計

好的設計

高內聚、低耦合 =>

1. (S) Modify A, do not break B
2. (O) Feature is stable, consistant
3. (L) Change detail but the user can not feel
4. (I) The user only uses the interface supplied for him/her
5. (D) The user only needs to focus on his/her abstract

在有設計前，先有 Context

瀑布模型本身就是一個有問題的模型，agile 只是為了解決他不是為了對抗它

測試的目的

1. 確保功能的正確
2. 支持你的 refactor

To Read

• 六角架構
• clean architecture