We see tools like Co-pilot, GitHub stating that they are now an AI company or the ever-talked-about soap opera that is ChatGPT and their ability to code so we wonder about where that leaves us.

As an engineer, I believe we will become inefficient if we don't leverage these tools. That isn't to say they should replace learning tools and languages, absolutely not! But we can use them to do some of the repetitive parts like code generation for human review.

Micro scale thoughts but what about looking wider and larger problem spaces...

It's important to remember that AI is not a monolithic entity. Rather, it's a collection of tools and technologies that can be used for a wide variety of purposes. While some AI applications may automate tasks that are currently performed by humans, others will create new opportunities that require new skills and expertise.

Google just released a new blog - "Google Cloud Partners Using AI for Sustainability" which highlights two examples of how AI is being used to create new opportunities in the technology industry. Actually using technology for good!

ESG Book is using AI to help investors make informed decisions about sustainable investments, while Watershed is using AI to develop predictive models that can help businesses optimize their energy use.

These are just two examples of the many ways in which AI is being used to create new jobs in the technology industry. As AI continues to develop, we can expect to see even more new opportunities emerge.

Of course, the transition to an AI-powered workforce will not be without its challenges. Some jobs will undoubtedly be lost to automation, and workers will need to adapt to the changing landscape of the technology industry. Being truly honest, I hate this part - I hope we retain the human spirit though and those skills that just cannot be performed by automation - creativity, passion, art - all the things that make us human.

However, there is also reason to be optimistic about the future of tech jobs.

AI is not just a threat to jobs; it's also a powerful tool that can be used to create new opportunities. By embracing AI and developing the skills needed to work with it, tech workers can ensure that they are well-positioned for success in the years to come.

Here are some specific tips for tech workers who are concerned about the impact of AI on their jobs:

• Develop strong technical skills. This includes programming, data analysis, and machine learning.

• Stay up-to-date on the latest AI trends. This will help you to identify new opportunities and adapt to the changing landscape of the industry.

• Be willing to learn new things. AI is constantly evolving, so you will need to be open to learning new skills and technologies.

• Focus on your creativity and problem-solving skills. These are skills that AI cannot easily replicate.

By following these tips, tech workers can ensure that they are well-positioned for success in the AI-driven economy of the future.

In fact, it even triggered an open-source fork of Terraform called Open Tofu

Why the Open Source Community is Upset

From what I can deduce, there are several reasons why some members of the Terraform community are upset about the change to HBSL.

• HBSL restricts the use of Terraform in commercial products. While HBSL is a permissive license, it does require commercial users to agree to certain terms, such as providing support for Terraform and not using it to compete with HashiCorp's commercial offerings. This has led some to worry that the change will make it more difficult to use Terraform in commercial products and that it will stifle innovation.

• HashiCorp has not been transparent about the reasons for the change. There has been some speculation that HashiCorp is trying to lock in its customers and prevent them from using Terraform alternatives. However, HashiCorp has not publicly stated its reasons for the change.

• The change has been made without community input. The Terraform community has been largely excluded from the decision-making process surrounding the change to HBSL. This has led to some feeling that HashiCorp is not respecting the community's input and that the change is being made in a self-serving way.

The contrasting perspective

I wonder if the crux of things is because of the change. We're not super great with change especially when it's unexpected. I remember reading once that it isn't the act that hurts when trust is damaged but rather it is the surprise of the damage that hurts.

That being said, commercial hat on, I can understand a perspective of being slightly miffed that competing products (once you've decided that revenue is important) are using the ground you've laid to make their competitor.

There could however be potential benefits of the change.

On the one hand, the change to HBSL could make it more difficult for commercial users to use Terraform. This could lead to some users switching to alternative IaC tools. However, it is important to note that HBSL is still a permissive license and that it still allows for a wide range of use cases. Additionally, there are a number of other open-source IaC tools available that can be used in commercial products.

On the other hand, the change to HBSL could give HashiCorp more flexibility to develop and innovate Terraform. It could also make it easier for HashiCorp to attract commercial support for Terraform. This could ultimately benefit the Terraform community as a whole.

Overall, I believe that the change to HBSL is a mixed bag for the Terraform community. There are potential benefits and drawbacks, and it is important to weigh these carefully. I hope that HashiCorp will continue to engage with the community and address the concerns that have been raised.

Conclusion

The change to HBSL is a significant change for the Terraform community. It is important for HashiCorp to continue to engage with the community and address the concerns that have been raised. I hope that the community will be able to work together to ensure that Terraform remains a thriving open-source project.

As of Terraform v1.6 and later, there is now native support for writing tests. This guide shows how to start writing unit tests with Terraform.

You might already be familiar with aspects like mocking dependencies when doing unit testing within software development projects and how it differs from integration testing.

With infrastructure testing, the definition of a unit test is the ability to test logic within your code before it is applied. Specifically for Terraform, this means checking the plan that Terraform generates and NOT applying the infrastructure changes.

I'll do a future post on integration tests when the infrastructure has been applied.

TL;DR

GitHub link to the code

https://github.com/eggsy84/terraform_unit_testing_gcp

Scenario

For this guide, rather than a simple main.tf that creates a storage bucket or something like that, let's assume that you have a Terraform project that makes use of local modules. One of those modules you've called networking and creates the VPC setup.

The root main.tf will make use of the networking module and for now, I'll just have the networking module create a VPC and a couple of subnets.

This is the directory structure

├── README.md
├── main.tf
├── modules
│   ├── networking
│   │   ├── main.tf
│   │   ├── outputs.tf
│   │   ├── providers.tf
│   │   └── variables.tf
├── outputs.tf
├── providers.tf
└── variables.tf

The module and usage

The networking module has been created to create a VPC and two subnets within that VPC - one for a production network and one for the development network.

The module takes in two variables and using some string-based logic, names the subnets as per Google naming recommendations.

To test this module you can expect that one of the "units" you might wish to test is that the subnets abide by the naming conventions.

Here's the code of the module

# Example networking module creates a dev and production subnet
# with a specified region. 
# Naming style for networks loosely based on Google Best Practices
# https://cloud.google.com/architecture/best-practices-vpc-design#naming

resource "google_compute_network" "vpc_network" {
  name                      = "${var.company_name}-app"
  description               = "VPC network for the ${var.company_name} app"
  auto_create_subnetworks   = false
}

# Example name for europe-west2 and company name Acme company app
# acme-app-eu-we2-prod-subnet
# acme-app-eu-we2-dev-subnet
resource "google_compute_subnetwork" "dev" {
  name          = "${var.company_name}-app-${substr(var.region, 0, 2)}-${substr(regex("-[a-z]+", var.region), 1, 2)}${substr(var.region, length(var.region) -1, 1)}-dev-subnet"
  ip_cidr_range = "10.128.0.0/20"
  region        = var.region
  network       = google_compute_network.vpc_network.id
}

resource "google_compute_subnetwork" "prod" {
  name          = "${var.company_name}-app-${substr(var.region, 0, 2)}-${substr(regex("-[a-z]+", var.region), 1, 2)}${substr(var.region, length(var.region) -1, 1)}-prod-subnet"
  ip_cidr_range = "10.154.0.0/20"
  region        = var.region
  network       = google_compute_network.vpc_network.id
}

The unit test

Looking at how the subnet names are defined, it feels like some business logic that should be tested and a good case for a unit case. We might want to test out some of that crazy string logic around different regions and company names.

In this guide, I'll take the approach that tests of the networking module are considered unit tests and shall be located within the module directory. In a later post, we'll create integration tests that sit within the root directory.

With that in mind, create a new directory within the networking module called tests and create a new file within that directory, let's call it naming_convention.tftest.hcl

The directory structure now looks similar to this:

.
├── README.md
├── main.tf
├── modules
│   └── networking
│       ├── main.tf
│       ├── outputs.tf
│       ├── provider.tf
│       ├── tests
│       │   └── naming_convention.tftest.hcl
│       └── variables.tf
├── outputs.tf
├── providers.tf
└── variables.tf

Let's create the first test, within the naming_convention.tftest.hcl file

variables {
  company_name  = "acme"
  region        = "europe-west2"
  project_id    = "example"
}

run "valid_naming_convention" {

  command = plan

  assert {
    condition     = google_compute_subnetwork.dev.name == "acme-app-eu-we2-dev-subnet"
    error_message = "Dev subnet name did not match expected naming convention"
  }

  assert {
    condition     = google_compute_subnetwork.prod.name == "acme-app-eu-we2-prod-subnet"
    error_message = "Prod subnet name did not match expected naming convention"
  }
}

📝 NOTE: At the time of writing (2023-10), the Terraform VS Code plugin doesn't observe or support the test code syntax so don't worry if you have lots of red squiggles or a lack of syntax highlighting.

The above code initiates the required variables for the module and then runs a test to assert that the correct name is applied to the subnet.

The global variables can also be overridden by local test variables. For example, we might wish to test an alternative region:

run "valid_dev_naming_convention_alternative_region" {

  command = plan

  variables {
    region        = "asia-east1"
  }

  assert {
    condition     = google_compute_subnetwork.dev.name == "acme-app-as-ea1-dev-subnet"
    error_message = "Dev subnet name did not match expected naming convention"
  }
}

The full test file can be viewed on GitHub

Running the test

The command you'll be using for executing the tests is terraform test. The command has various options which you can find on the documentation. At the time of writing it will, by default, look for a tests directory within the current working directory and execute tests from there. You can specify the -test-directory but it seems to read the terraform config relatively.

With this in mind, to run tests you've created within the networking module we'll navigate to it first, init the module (to ensure the GCP provider can be read) and then run test

cd modules/networking 

terraform init

terraform test

You should then see Terraform read the tests and execute them

tests/naming_convention.tftest.hcl... in progress
  run "valid_dev_naming_convention"... pass
  run "valid_dev_naming_convention_alternative_region"... pass
tests/naming_convention.tftest.hcl... tearing down
tests/naming_convention.tftest.hcl... pass

Success! 2 passed, 0 failed.

Hopefully, all is well, your tests ran and you can see some output.

In a future post, we'll add integration tests that bring together multiple modules and perform an integration test of things.