Forem: Piotr Gwiazda

Smart unit testing

Piotr Gwiazda — Thu, 08 Sep 2022 09:48:12 +0000

The goal of smart unit testing is to replace runtime functional testing with build-time functional tests and don’t get tired and angry. You not only want to check your code now. You want to check everybody elses’ changes in the next few years as well - did they break your code? This is actually the purpose of unit testing but "smart" is just in this headline to make it catchy :-)

We’ll focus on functional unit tests here. Technical unit tests that cover some specific engineer-facing aspects, reliability-related corner cases, multithreading consistency etc. are out of the scope of this post.

About mechanical unit tests

The "unit test" term is one of the most unfortunate names in software engineering. Thousands of developers are writing tons of "tests per class" mechanically, tests that bring small to no value and then paint themselves into the corner as they cannot refactor the code without touching those tests. After this bad experience, they stop writing tests.

First and the easiest step to avoid mechanical testing is to stop following your package structure in tests. You need to allow code refactoring without touching tests. Don't bind these two structures. Allow for breaking down classes into smaller ones, moving them between packages, and extracting methods by not expecting anything from the internal code structure. This is not what you want to test.

A unit of functionality

A functional unit test should test a unit of functionality, a scenario in a story.
"Dao should return false" is not a good test. Try using the domain language: “A trade with not recognized instrument ID should not be executed” sounds better. Using BDD frameworks may force using this language and also force separate production code and test structures. Writing tests in the Gherkin language is hard, but you may want to try it.

When writing a test, think about the client of your code module. Who or what is going to use it? What depends on it? The front end, another module, another service, user? Who or what expects certain behavior? This is how you find the contract.

With tests, you describe how clients can use your module to achieve what they expect. With tests, you also verify and describe what the system cannot do. Usually, there are twice as many negative tests as positive tests. As a result, any functional change in production code should make a test fail. Any good refactoring, should not.

Unit of code

You should be able to refactor the whole internal module code but cannot change the contract, as someone or something depends on this. Test through the interface that implements the contract like the API, façade classes, controllers etc. (note that the contract testing technique is something else, not covered here). Don't test through internal classes. Tests must allow for safe refactoring - it is safe when you don’t have to touch the tests when doing refactoring.

*A unit of code that implements needed functionalities and is bounded by interfaces implementing contract is your module to test. *

A microservice is not the worst concept of a module, but it can be a subdomain module inside, one or a few aggregates.
A class is a bad idea.
A layer (just DAO, just Controller) as well is a bad idea. Layers are not modules.
Small backend-for-frontend tested through REST API (or controllers) might be a good unit of code.

Are you worried about “monolith”? Look around, what is the role of your software in the organization? Most likely it is doing one thing in one domain - e.g. handling invoices or doing financial reporting. It may turn out that what you do is a microservice in a wider scope. An average monolith from the 90s is half a million lines of code and 40+ developers working on it at the same time. And still, a modular monolith is not a bad thing as long as modules have clear contracts, and interfaces and you can test them separately.

Remind me, why we do that

Software development agility means bringing a constant stream of value into the hands of the users (which means a production environment) with high-quality software. Everything else is just a distraction. You don’t achieve agility by applying Scrum, SAFe or any other framework. You can achieve agility by starting to deliver value sooner to its users. For this, you need to eliminate or at least reduce to a minimum any manual effort related to quality assurance.

Good unit tests allow for continuous refactoring and growing the solution incrementally in a safe way, without manual regression testing. Your code must be safe for modification by other engineers in the future. Your tests should guide them and let them feel confident when modifying your code.

Make sure you’re not producing legacy code.

Main-module approach for handling multiple environments in Terraform

Piotr Gwiazda — Wed, 26 Feb 2020 08:57:39 +0000

Handling multiple environments in Terraform might be challenging and you can find many approaches and best practices on the Internet. Ths "main-module" approach is one of them using just built-in Terraform concepts (as an alternative to Terraform workspaces with Terraform Cloud/Enterprise or using wrapper tools like Terragrunt).

But why not just use “tfvars” files?
Because you cannot use variables in backend and provider configuration blocks.

Goals:

Have separate backends for Terraform remote state-files per environment
Be able to use separate system accounts for different environments
Be able to use different versions of providers and Terraform itself per environment (and upgrade one by one)
Ensure that all required properties are provided per environment (Terraform validate won't pass if an environmental property is missing)
Ensure that all resources/modules are always added to all environments. It is not possible to "forget" about a whole module.

Here is a basic structure of a Terraform project with the main-module approach that worked for me and few other teams:

- terraform_project
  - env
     - dev01        <-- Terraform home, run from here 
        - .terraform    <-- git ignored of course
        - dev01.tf  <-- backend, env config, includes always _only_ the main module
     - dev02
        - .terraform
        - dev02.tf 
     - stg01
        - .terraform
        - stg01.tf
     - prd01
        - .terraform
        - prd01.tf 
  - main        <-- main umbrella module
     - main.tf
     - variables.tf         
  - modules         <-- submodules of the main module
     - module_a
     - module_b
     - module_c

And a real-life example screenshot:

env
Each env subdir is a Terraform "home".
Run terraform init/plan/apply in these directories. Change the environment by changing the directory. This prevents an error of merging state files of multiple environments.

Sample dev01.tf file (part):

provider "azurerm" {
  version = "~>1.42.0"
}

terraform {
  backend "azurerm" {
    resource_group_name  = "tradelens-host-rg"
    storage_account_name = "stterraformstate001"
    container_name       = "terraformstate"
    key                  = "dev.terraform.terraformstate"
  }
}

module "main" {
  source               = "../../main"
  subscription_id      = "000000000-0000-0000-0000-00000000000"
  project_name         = "tlens"
  environment_name     = "dev"
  resource_group_name  = "tradelens-main-dev"
  tenant_id            = "790fd69f-41a3-4b51-8a42-685767c7d8zz"
  location             = "West Europe"
  developers_object_id = "58968a05-dc52-4b69-a7df-ff99f01e12zz"
  terraform_sp_app_id  = "8afb2166-9168-4919-ba27-6f3f9dfad3ff"

  kubernetes_version      = "1.14.8"
  kuberenetes_vm_size     = "Standard_B2ms"
  kuberenetes_nodes_count = 4

  enable_ddos_protection = false
  enable_waf             = false
}

This gives a possibility to configure backend and provider per environment as well as provide all required parameters to the main module (i.e. the environment)

main

This is the main module that is an umbrella module for the whole Terraform project.

Having this module ensures that each environment will be as similar as possible to other environments. Adding a new resource or module to the main module will add this to all environments.

In order to implement differences between environments (pricing tiers etc.) use flags and parameters.

The variables.tf file lists the required parameters for an environment. Environment-specific settings.

Sample variables.tf file (part)

variable "subscription_id" {
  description = "Azure Subscription ID"
  type        = string
}

variable "project_name" {
  description = "Project name"
  type        = string
}

variable "environment_name" {
  description = "Environment name"
  type        = string
}

variable "resource_group_name" {
  description = "Target resource group name"
  type        = string
}

...

The main module can include submodules and resources. However, it is a good practice to divide it into a few submodules to introduce some encapsulation, increase readability and limit dependencies between resources.

Any shared remote resources will be included here.

A sample main.tf file (part):

module "eventhub" {
  source              = "../modules/eventhub"
  environment_name    = var.environment_name
  resource_group_name = var.resource_group_name
  project_name        = var.project_name
}

module "dremio" {
  source                   = "../modules/dremio"
  environment_name         = var.environment_name
  resource_group_name      = var.resource_group_name
  project_name             = var.project_name
  linux_admin              = "dremio"
  linux_admin_password     = "1b4d7c79-a143-45e2-8ff1-ee63c0823090"
  dremio_data_name         = module.dremio_storage.dremio_data_name
  dremio_data_id           = module.dremio_storage.dremio_data_id
  dremio_data_disk_size_gb = module.dremio_storage.dremio_data_disk_size_gb
}

module "dremio_storage" {
  source              = "../modules/dremio-storage"
  resource_group_name = var.resource_group_name
  project_name        = var.project_name
}


module "datalake" {
  source              = "../modules/datalake"
  resource_group_name = var.resource_group_name
  project_name        = var.project_name
  environment_name    = var.environment_name
}

This should be enough to visualize the concept.