|
1 | 1 | # Testing |
2 | 2 |
|
| 3 | +## Table of Content |
| 4 | + |
| 5 | +- [Golden files](#golden-files) |
| 6 | +- [Unit testing](#unit-testing) |
| 7 | + - [Mocks](#mocks) |
| 8 | + - [Mocking repositories](#mocking-repositories) |
| 9 | +- [Acceptance testing](#acceptance-testing) |
| 10 | + - [Credentials](#credentials) |
| 11 | + - [AWS](#aws) |
| 12 | + - [Workflow](#workflow) |
| 13 | + - [Example](#example) |
| 14 | + |
| 15 | + |
3 | 16 | driftctl uses **unit tests**, **functional tests** and **acceptance tests**. |
4 | 17 |
|
5 | 18 | - A **unit test** tests only a very specific part of code |
@@ -44,6 +57,8 @@ For example, we don't care about covering `NewStruct()` constructors if there is |
44 | 57 | Remember, a covered code does not mean that all conditions are tested and asserted, so be careful to test the right things. |
45 | 58 | A bug can still happen in a covered part of your code. |
46 | 59 |
|
| 60 | +## Golden files |
| 61 | + |
47 | 62 | We use the golden file pattern to assert on results. Golden files could be updated with `-update flag`. |
48 | 63 | For example, I've made modifications to s3 bucket policy, I could update golden files with the following command: |
49 | 64 |
|
@@ -82,7 +97,10 @@ type FakeEC2 interface { |
82 | 97 | } |
83 | 98 | ``` |
84 | 99 |
|
85 | | -2. Use mockery to generate a full mocked struct `mockery --name FakeEC2 --dir ./test/aws` |
| 100 | +2. Use mockery to generate a full mocked struct |
| 101 | +``` |
| 102 | +$ mockery --name FakeEC2 --dir ./test/aws |
| 103 | +``` |
86 | 104 | 3. Mock a response in your test (list IAM users for example) |
87 | 105 |
|
88 | 106 | ```go |
@@ -130,6 +148,33 @@ client.On("ListUsersPages", |
130 | 148 | ).Once().Return(nil) |
131 | 149 | ``` |
132 | 150 |
|
| 151 | +#### Mocking repositories |
| 152 | + |
| 153 | +Repositories are an abstraction layer for data retrival. They're used by enumerators to retrieve data from a cloud provider through its SDK. For example, each AWS service has a repository attached. We only implement repositories and methods we need. Mocking repositories is almost the same process than mocking the cloud provider's SDK. |
| 154 | + |
| 155 | +Since there's an interface for each repository, generating a mock for it is quick and easy. Note the difference between the interface and struct here. Remember a struct cannot be mocked in Go. |
| 156 | + |
| 157 | +```go |
| 158 | +type ECRRepository interface { |
| 159 | + ListAllRepositories() ([]*ecr.Repository, error) |
| 160 | +} |
| 161 | + |
| 162 | +type ecrRepository struct { |
| 163 | + client ecriface.ECRAPI |
| 164 | + cache cache.Cache |
| 165 | +} |
| 166 | +``` |
| 167 | + |
| 168 | +Here's an example that will create a mock for the ECR repository : |
| 169 | + |
| 170 | +``` |
| 171 | +$ mockery --name=ECRRepository --dir pkg/remote/aws/repository/ |
| 172 | +``` |
| 173 | + |
| 174 | +`ECRRepository` is the name of the interface present in the `pkg/remote/aws/repository/` directory. |
| 175 | + |
| 176 | +---- |
| 177 | + |
133 | 178 | 🙏 We are still looking for a better way to handle this, contributions are welcome. |
134 | 179 |
|
135 | 180 | References: |
|
0 commit comments