| Conditions | 12 | 
| Total Lines | 61 | 
| Code Lines | 42 | 
| Lines | 0 | 
| Ratio | 0 % | 
| Changes | 0 | ||
Small methods make your code easier to understand, in particular if combined with a good name. Besides, if your method is small, finding a good name is usually much easier.
For example, if you find yourself adding comments to a method's body, this is usually a good sign to extract the commented part to a new method, and use the comment as a starting point when coming up with a good name for this new method.
Commonly applied refactorings include:
If many parameters/temporary variables are present:
Complex classes like random_test.TestGenerator_GenerateSecretCode often do a lot of different things. To break such a class down, we need to identify a cohesive component within that class. A common approach to find such a component is to look for fields/methods that share the same prefixes, or suffixes.
Once you have determined the fields that belong together, you can apply the Extract Class refactoring. If the component makes sense as a sub-class, Extract Subclass is also a candidate, and is often faster.
| 1 | package random_test  | 
            ||
| 11 | func TestGenerator_GenerateSecretCode(t *testing.T) { | 
            ||
| 12 | generator := random.GetRandomGeneratorInstance()  | 
            ||
| 13 | |||
| 14 | 	testCases := []struct { | 
            ||
| 15 | expectedErr error  | 
            ||
| 16 | name string  | 
            ||
| 17 | n int  | 
            ||
| 18 | expected int  | 
            ||
| 19 | hasErr bool  | 
            ||
| 20 | 	}{ | 
            ||
| 21 | 		{ | 
            ||
| 22 | name: "GenerateSecretCodeWithLength10",  | 
            ||
| 23 | n: 10,  | 
            ||
| 24 | expected: 10,  | 
            ||
| 25 | expectedErr: nil,  | 
            ||
| 26 | hasErr: false,  | 
            ||
| 27 | },  | 
            ||
| 28 | 		{ | 
            ||
| 29 | name: "GenerateSecretCodeWithLength20",  | 
            ||
| 30 | n: 20,  | 
            ||
| 31 | expected: 20,  | 
            ||
| 32 | expectedErr: nil,  | 
            ||
| 33 | hasErr: false,  | 
            ||
| 34 | },  | 
            ||
| 35 | 		{ | 
            ||
| 36 | name: "GenerateSecretCodeWithLength0",  | 
            ||
| 37 | n: 0,  | 
            ||
| 38 | expected: 0,  | 
            ||
| 39 | expectedErr: nil,  | 
            ||
| 40 | hasErr: false,  | 
            ||
| 41 | },  | 
            ||
| 42 | 		{ | 
            ||
| 43 | name: "GenerateSecretCodeWithLengthNegative",  | 
            ||
| 44 | n: -1,  | 
            ||
| 45 | expected: 0,  | 
            ||
| 46 | 			expectedErr: errors.New("invalid length"), | 
            ||
| 47 | hasErr: true,  | 
            ||
| 48 | },  | 
            ||
| 49 | }  | 
            ||
| 50 | |||
| 51 | 	for _, tc := range testCases { | 
            ||
| 52 | 		t.Run(tc.name, func(t *testing.T) { | 
            ||
| 53 | code, err := generator.GenerateSecretCode(tc.n)  | 
            ||
| 54 | 			if tc.hasErr && err == nil { | 
            ||
| 55 | 				t.Fatalf("Expected error, but got nil") | 
            ||
| 56 | }  | 
            ||
| 57 | |||
| 58 | 			if !tc.hasErr && err != nil { | 
            ||
| 59 | 				t.Fatalf("Unexpected error: %v", err) | 
            ||
| 60 | }  | 
            ||
| 61 | |||
| 62 | 			if tc.hasErr && err != nil && err.Error() != tc.expectedErr.Error() { | 
            ||
| 63 | 				t.Fatalf("Expected error to be %v, but got %v", tc.expectedErr, err) | 
            ||
| 64 | }  | 
            ||
| 65 | |||
| 66 | 			if len(code) != tc.expected { | 
            ||
| 67 | 				t.Errorf("Expected code length to be %d, but got %d", tc.expected, len(code)) | 
            ||
| 68 | }  | 
            ||
| 69 | |||
| 70 | 			if !isValidCode(code) { | 
            ||
| 71 | 				t.Errorf("Generated code is not valid: %s", code) | 
            ||
| 72 | }  | 
            ||
| 109 |