Unit testing code of conduct

[ameteiko]

General

Small

The unit test must be as concise as possible and not contain any sophisticated logic, for it will make it bug-prone and more challenging to maintain.

Anti Example:

for i := range testcases {
	testcase := testcases[i]
	t.Run(testcase.name, func(t *testing.T) {
		t.Parallel()

		kymaBuilder := builder.NewKymaBuilder().
			WithCondition(apimetav1.Condition{
				Type:   string(v1beta2.DeprecatedConditionTypeReady),
				Status: apimetav1.ConditionFalse,
				Reason: "Deprecated",
			}).
			WithCondition(apimetav1.Condition{
				Type:   "ThisConditionShouldBeRemoved",
				Status: apimetav1.ConditionFalse,
				Reason: "Deprecated",
			})

		if testcase.hasSyncLabel {
			labelValue := shared.DisableLabelValue
			if testcase.syncLabelValueEnabled {
				labelValue = shared.EnableLabelValue
			}
			kymaBuilder.WithLabel(shared.SyncLabel, labelValue)
		}
		kyma := kymaBuilder.Build()

		status.InitConditions(kyma, kyma.HasSyncLabelEnabled(), testcase.watcherEnabled)

		// There is no need to use this external dependency.
		// Just test over the preconfigured set.
		requiredConditions := v1beta2.GetRequiredConditionTypes(kyma.HasSyncLabelEnabled(), testcase.watcherEnabled)
		if !onlyRequiredKymaConditionsPresent(kyma, requiredConditions) {
			t.Error("Incorrect Condition Initialization")
			return
		}
	})
}

Fast

The unit test must not operate over any real dependency (any operate over a test double instead), making it fast to execute.

Simple

Avoid any complex logic in the tests because it will lead to the necessity of testing them, too.

Any generic logic that would shorten the test code by following a DRY perspective will inevitably fail at some point, leading to debugging this logic together with the test to find the problem.

Generic code will grow in complexity over the time making tests also subject to refactoring. It is crucial to find a good balance between simplicity and repetitiveness.

Anti example

for _, testCase := range tests {
	testCase := testCase
	t.Run(testCase.name, func(t *testing.T) {
		t.Parallel()
		kyma := testutils.NewTestKyma("test-kyma")
		configureModuleInKyma(kyma, testCase.ModulesInKymaSpec, testCase.ModulesInKymaStatus)
		sync.DeleteNoLongerExistingModuleStatus(context.TODO(), kyma, testCase.getModule, nil)
		var modulesInFinalModuleStatus []string
		for _, moduleStatus := range kyma.Status.Modules {
			modulesInFinalModuleStatus = append(modulesInFinalModuleStatus, moduleStatus.Name)
		}
		sort.Strings(testCase.ExpectedModulesInKymaStatus)
		sort.Strings(modulesInFinalModuleStatus)
		assert.Equal(t, testCase.ExpectedModulesInKymaStatus, modulesInFinalModuleStatus)
	})
}

It is better to use assert.ElementsMatch instead of in-place sorting.

Readable

Unit tests should be easy to read and clear in their intent so that the developers can easily understand what is being tested under which conditions. To facilitate this, it’s best to structure the unit test according to the AAA pattern.

Naming

Test files

The unit test files should be named according to the Golang convention as *_test.go and reside next to the code under test. If the code inside a test file grows too big, it is recommended to split it into several files with prefixes that describe the clustering of the files:

manifest 
    ready_check.go
    ready_check_handle_state_test.go
    ready_check_run_test.go

The name of the should reflect the system under test:

TBD

• Test doubles naming and location.

Test scenarios

There are two main conventions for naming the test scenarios:

Name	Example	Description
Sustem under test	TestParseHeader
Sutem unter test with input and expected output	TestParseHeader_ForMalformedHeader_ReturnsError	MethodName_StateUnderTest_ExpectedBehavior

Anti Example

func Test_defaultTransforms(t *testing.T) {
// ...

Test doubles

The most used test doubles are:

• Stubs are implemented ad-hock.
• Mocks are automatically generated.

TBD

• Test doubles naming pattern
• Test doubles placement

Descriptive variable names

Variable names should describe the tests’ expected inputs and states to make unit tests to be more readable. Verbosity is acceptable if it improves readability.

Organisation

Easy to find

TBD:

• Where to find unit, e2e and integration tests
• Where to find test dobles

Test file organisation

TBD:

• When to use test suites
• Where to put test-supporting code (test kit, utility functions, in-place stubs and mocks)

Assertion

Follow the Arrange/Act/Assert (AAA) principle

1. Use line breaks to visually separate the three AAA parts in the body of your tests.
2. Don’t repeat the logic under test in your assertions.
3. Have a single Act and Assert parts in your tests.
4. Prefer assertion methods for strings: Contains(), StartsWith() and Matches()

Favour Precise Assertions

TBD:

• How atomic test should be
• Testing the happy-path and corner cases

Test data

Make your scenario under test and test values extremely obvious

Do not use magic constants

Try to avoid predefined constants in test fixtures and using constants for test pre-configuration. Use meaningful variables instead.

Test doubles

Use fakes when you depend on external systems you don’t control

TBD:

• Using stubs over mocks
• Replacing real dependencies with test doubles by adhering to the ISP (Interface Segregation Principle) and idiom "receive interfaces, return objects".

Avoid complex logic inside your fakes

The test doubles must simplify the behaviour of the external dependencies and not contain any complex logic (which can become a subject for testing on its own)

Don’t write assertions for stubs

Stubs should simulate the expected behaviour of an external dependency in a simple and predictable way. It should never change its state or cause any side effects.

Keep one mock per test

Mocks are used for assessing the interactions of the system under test with an an external dependency. There should be just one aspect of testing in each unit test, meaning that it should utilise just one mock for a unit test.

Design

Test one concept at a time in Isolation

Unit test isolation

Keep unit tests stateless

Recognise a test setup pain as a design smell

One use case per unit test

Checklist

• Is the test independent?
• Does the test represent a single unit of work?
• Can the test be executed on its own or is it dependent on the outcome of tests that preceded it?
• Is the test durable?
• Is the test designed so that it isn’t susceptible to changes in other parts of the application?
• Does the test have complex or lengthy setup?
• Will changes in the subject's dependencies lead to breakages?
• Is the test isolating responsibilities of the subject?
• Does the test make any assumptions about the internals of dependencies that aren't immediately related to the subject?
• Is the test inaccurately or indirectly testing a responsibility or implementation of another object?

TBD

• Black box vs white box unit testing approach.