Skip to content

Conversation

@goruha
Copy link
Member

@goruha goruha commented Mar 8, 2025

what

  • Added writing components testing guide

why

  • Allow contributors to add components tests

@goruha goruha requested a review from milldr March 8, 2025 00:03
@goruha goruha requested a review from osterman March 8, 2025 07:57
@goruha goruha self-assigned this Mar 8, 2025
Co-authored-by: Dan Miller <miller0daniel@gmail.com>
Co-authored-by: RoseSecurity <72598486+RoseSecurity@users.noreply.github.com>
milldr
milldr previously approved these changes Mar 18, 2025
Co-authored-by: RoseSecurity <72598486+RoseSecurity@users.noreply.github.com>
@goruha goruha merged commit 9c0ef1b into master Mar 18, 2025
2 checks passed
@goruha goruha deleted the component-testing-guide branch March 18, 2025 19:36
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When I see a component named like step-1 and then step-2, it seems like we are advocating a naming convention. Is this the naming convention we use?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no. this is files that reference examples for specific step number in Write test section

@@ -0,0 +1,812 @@
---
title: Components Testing
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
title: Components Testing
title: Component Testing

@@ -0,0 +1,812 @@
---
title: Components Testing
sidebar_label: Components Testing
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
sidebar_label: Components Testing
sidebar_label: Component Testing

---
title: Components Testing
sidebar_label: Components Testing
description: 'Our components testing strategy and resources'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
description: 'Our components testing strategy and resources'
description: 'Our guide for implementing automated component testing with Terratest'

</Step>

<Step>
### <StepNumber/> Install Go Lang
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
### <StepNumber/> Install Go Lang
### <StepNumber/> Install Golang

Build a Geodesic infrastructure container. This container that has all the tools like terraform and atmos for building infrastructure. It's built from the `Dockerfile` and there are some predefined targets defined in the `Makefile` to make this easy. Customize these for your organization. Here are examples of both for reference.

<CollapsibleText type="medium">
<CodeBlock title="Dockerfile">{PartialDockerfile}</CodeBlock>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we deleting this?

Import the dependent component for `default-test` stack
<CodeBlock language="yaml" title="test/fixtures/stacks/orgs/default/test/tests.yaml">{Step3Stack}</CodeBlock>

Add the dependent component to test suite with go code
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Add the dependent component to test suite with go code
Add the dependent component to test suite with Go code


Add the dependent component to test suite with go code
By default, the test suite will add a unique random value to the `attributes` terraform variable.
This is to avoid resoureces naming collision with other tests that are using the same component.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
This is to avoid resoureces naming collision with other tests that are using the same component.
This is to avoid resource naming collisions with other tests that are using the same component.

By default, the test suite will add a unique random value to the `attributes` terraform variable.
This is to avoid resoureces naming collision with other tests that are using the same component.
But in some cases, you may need to pass unique value to specific input for the component.
Check advanced example of the most common use case - dns delegated domain name.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Check advanced example of the most common use case - dns delegated domain name.
Check out the advanced example for the most common use-case with the `dns-delegated` domain name.


Component testing framework assumes that each component's repo structure follows the convention when all component terraform source code
would be stored in `src` directory and everything related to tests will be placed in `test` directory.
Tests consists of two coupled parts - atmos configuration fixtures and tests written on go code.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Tests consists of two coupled parts - atmos configuration fixtures and tests written on go code.
Tests consists of two coupled parts - atmos configuration fixtures and tests written on Go code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants