Forem: Kryštof Řeháček

How does 10x programmer test code?

Kryštof Řeháček — Mon, 10 Jun 2024 12:59:30 +0000

I would like to share a pattern for unit testing that I discovered while reading through the repository of one of our dependencies. It's about testing through object representation.

Problems with Testing Code

I perceive many problems with testing, but two main ones stand out:

It’s difficult to write unit tests that test what they should and don't degrade over time.
It’s hard to write unit tests quickly.

Our mindset is to develop features as quickly as possible, even at the cost of sometimes breaking things. We don't have the capacity or appetite for 100% test coverage. This post is for similarly-minded programmers.

Senior developers are here to create well-structured designs and deliver features. Therefore, they don't have time to write good tests and delegate such work to junior colleagues.

Juniors don't know how to properly test code, so they test everything they can think of, as they were taught in school. What they do is just cover the code in concrete.

Tests become unreadable in half a year, making it hard to understand what they test. If changes are made to the "concreted code" later, tests break, requiring fixes. If they aren't readable, they can't be fixed, and the test rots – it gets deleted or modified just to pass, and the problem grows.

How to Write Simple Tests?

Let's look at the test below. A simple test, checking that the items of the following invoice will be as expected. A very simple example, but it takes a moment to decode what exactly it tests.

def test_subscription_with_usage_first_tier(self):
        self.subscription.record_usage(quantity=5, created_at=aware_date(2020, 6, 1))

        usage_summary_group = self.subscription.get_upcoming_invoice_item_groups(
            aware_date(2020, 6, 1), aware_date(2020, 7, 1)
        )

        self.assertEqual(usage_summary_group.price, Decimal(4.5))
        self.assertEqual(usage_summary_group.currency, "CZK")
        self.assertEqual(len(usage_summary_group.items), 1)
        self.assertEqual(usage_summary_group.items[0].price, Decimal(5))
        self.assertEqual(usage_summary_group.items[0].currency, "CZK")
        self.assertEqual(usage_summary_group.items[0].quantity, 5)
        self.assertEqual(usage_summary_group.items[0].get_discounted_price(), Decimal(4.5))
        self.assertEqual(usage_summary_group.items[0].discount_name, "Discount 10%")
        self.assertEqual(usage_summary_group.items[0].discount_percent_off, 10)

An alternative I offer as a solution is to define a __repr__ method for such an object that includes all relevant values.

def test_subscription_with_usage_first_tier(self):
    self.subscription.record_usage(quantity=5, created_at=aware_date(2020, 6, 1))

    usage_summary_group = self.subscription.get_upcoming_invoice_item_groups(
        aware_date(2020, 6, 1), aware_date(2020, 7, 1)
    )
    self.assertEqual(
        repr(usage_summary_group),
        "<UpcomingInvoiceItemGroup 4.50 CZK: Product - Tier 1 (x5) 5.00 CZK (Discount 10% = 0.50 CZK)>",
    )

The test below tests the same thing as the first test. The difference is that the second test tests the string representation of the object instead of checking all the attributes.

The second test is much faster to write and significantly easier to read. Writing readable tests is one of the key factors in ensuring that a test doesn't rot over time.

But there's a catch. By not testing the object's attributes, there can be an error in the definition of the __repr__ method.

This means that such a solution is a tradeoff. By trusting the __repr__ method, I've written a test that is easy to read and faster to write. However, this could be the difference between having tested code and code for which no test exists.

Conclusion

If you test your code and have no problems with it, you're probably doing it right. However, if you don't have time to write tests, this solution could provide simple, readable, and maintainable tests.

Pull Request Checklist

Kryštof Řeháček — Mon, 31 May 2021 12:19:45 +0000

Hello there 👋 I've created an ultimate pull request checklist which summarises some of the best practises we pursue in every pull request.

There are many blogposts about merge review checklists, but none of them covered everything I wanted so I've created my own.

Authors should memorise it and apply these rules when making a pull request. Otherwise you'll burn reviewer's time and later your time fixing the threads (that you could prevent).

We are using Gitlab for vcs, Django on BE and React w/ typescript on FE. So few points may be related to them.

There it is:

Guide to merge requests

Review your code outside the editor you've written the code in and review the code once more in VCS.
Have a clear understanding of the problem and set the expectations on what it should do and how before you start to code. Evaluate this once more when you do a self-review.
You should be able to draw a simple diagram and explain your solution to some colleague. This will help you find any possible problems before you start to code.

Code & Design

Does it do what it is supposed to do?
Did you remove everything that is not supposed to be there?
Aren't there any debug prints or TODO comments you want to do or remove?
Is the branch up-to-date with master?
Isn't there any conceivable way this could break other parts of the system?
Check all of the possible edge cases and have a solution for them.
Is the code easy to read and understand? Did you choose the best names and organise things as cleanly as possible?
- name should not involve any historical context
- name should be clear to any developer who passes by or sees the code for the first time
Isn't the functionality you've added already implemented somewhere else? If it's duplicated, reconsider the design.
- if you cannot figure out how to deduplicate the code, try drawing a diagram of the system and find the pure underlying abstraction - there is always an answer
Is there a single source of truth to every piece of logic?
Ask yourself - How much expertise and context will anybody reading this code need to understand?
Did you introduce any new abstractions?
- Don't they cause additional complexity that can be achieved without the abstraction?
- Are you able to draw a simple diagram of the system?
- Did you ever see similar abstraction in some other software?
- Is it as simple as possible?
- Will it be easy to expand with more features? Have you thought about what other features we could add there and if it's possible?
Is there anything you are not sure about? Just ask.

Frontend

Did you use already implemented ui components?
Is UI visually consistent? (font size, line height, margin, padding)
Can you find similar UI in other software?
- Our's shouldn't be different, else explain why it is so.
If you added any complex multi-step flow, then you should be able to draw a diagram of it and explain it including possible branches and error validation.
Does it look OK on phone?
How is the copy? Are sentences well-formed and clear? Any spelling error or typos?
What if the request to the backend fails?
Did you make any changes to the component in the ui or components? Check if all usages of the component still work as expected.

Backend

Aren't there any possible security threats?
Isn't any private data exposed to the public? Is the public part of the app available to the public?
Aren't there any circular module dependencies?
Did you add any inline import?
- Why it's so? Are you able to draw a simple diagram of the system and explain?
Models should not have any methods which doesn't really belong there.
Are there any issues that will become problems in the next months or years?
- Thing them out and discuss them with the reviewer in the merge request.
Does the new classes or modules have only single responsibility?
Is it possible to write tests for this functionality?
What if anything fails? Prevent side-effects before changes are committed.

Migrations checklist

Understand that a migration can corrupt data and it is extremely difficult (sometimes impossible) to fix it. A single wrong migration can result in several man-days burnt in vain. We've been through this. It's not nice. Be careful.

Migrations should be always, reversible. When it's data transformation, you must write reverse transformation.
Never delete a column that was previously used, instead keep the field in the model and mark it with comment # DEPRECATED in version vX.Y.Z
Never delete data that is used – if you need to transform data, create a new column and do the transformation there, keep the original data in the original column, use deprecation comment or prepend old_ to the column
If you have experimented with database schema before settling for a final solution, squash your migrations
Be extra careful about migrating large tables – there may be millions of rows in that tables and not all operations are safe to run, because it would take too long and fail
- in that case, create async task which should be run after the code is deployed. Pay attention on that the task should be resumable, because it can be interrupted by failure or another deploy.
Always use queryset.iterator(), which will prevent memory issues
Log migration progress by step of reasonable size
When doing data transformation, create some sample data, so you can correctly handle the edge cases

Peer review

Use this chrome extension to easily see unresolved threads on merge requests. (Gitlab only)
Check all of the points above and create merge request threads for any violations.
Merge request threads should not be resolved without any comment, because then the reviewer needs to check the resolution by himself and it's a waste of time.
You should ask the reviewer to review your merge request, it will be merged faster. If it takes too long, the author will lose context of the issue and it will take more time to him and the reviewer fix and review it again.

Feedback is much appreciated.

Project idea: An app measuring time spent waiting for code changes

Kryštof Řeháček — Fri, 04 Sep 2020 19:56:00 +0000

Have you ever thought how much time do you spend waiting on your code to compile? On your local development server to reload or refreshing your browser for some UI change in your code?

I've been thinking about it a lot for past few days, because it bothers me to spend time just waiting and looking on spinning loaders.

Yeah, sure, there are things like hot module replacement to boost your productivity, but that's NOT what I want to talk about.

I want to talk about the question - How much time do I actually spend waiting for these things every day. And sure, I've been thinking how to measure it.

What if I made an app to measure these reload times, on the server-side (your local server) and client-side (in the browser). Which could show you at the end of the day that you spend 38 minutes just waiting for your code to compile? Would you be interested in using it?

There are some other interesting things you could get from the data, like automatically measuring your time in work, which is another thing I would like to know.

You might be wondering about the technical implementation. I can explain it in another post if it has shown to be interesting.

I'm learning Go the hard way

Kryštof Řeháček — Mon, 08 Jul 2019 22:21:31 +0000

This is my first blog post ever.

This is not tutorial to Golang, but my story why I chosen to start learning Go and how I do it.

Few days ago, I've decided to implement rest api client for RegioJet (which is one of biggest Czech private carriers, link). My first plan was to write it in Python, which I think I'm getting pretty good at it, but I've already done many rest api integrations and... there is nothing new to be surprised of when doing it again in the same environment.

Goals of this project

Learning how to make web app in Golang.
Having web app which will unify seat and ticket reservation across many transport carriers.

Imagine that you want to take busy train connection at afternoon which is full at the morning. I know many people that are buying tickets a month before. I'm not really that kind of guy. I like to decide when I commute at the earliest one day at the advance or, even better, on that day. If you ever experienced this, you may noticed that trains are sold out that the time you've decided. And if so, then you may notice that some people are likely to sold their tickets few hours before. I would rather say it is a rule than an exception that some people sell their tickets on the day of the trip and if you check the website of the carrier often, you can be lucky to get their seat. This is what I do and ahis also does many other people and if you are not fast enough you won't be the lucky guy.
My vision is that I will choose when and where I want to go and it will handle the reservation of the ticket for me. Yes, it is not 100% reliable that I would be able to get a seat, but it can be handled by some other carriers which do not require seat reservation (means you can ride even if the train is completely sold out).

Why in Go?

I think I'm getting pretty good at web development using Python and Django. Nowadays I have 2 years of experience with Django and DRF on a daily basis (to boast, I recently made a contribution to DRF :) ).
I could definitely make this project in Django without learning anything new, just to have the final product. Getting things done is hard, and the output will be just an app, without learning much new.
So more exciting way to do, will be writing it in a language that I don't know at the time I'm writing this post (except some basics). The development will be much more interesting, and even if I do not finish this project, I will learn a lot.

Let's jump into it

I'will start with building the backend (as expected from this post about my go). My plan is:

write api client package using mainly standard library
choose framework and create web REST backend (Beego or Gin)
create simple frontend in React

The most interesting thing will be first point in my oppinion. Second point will be just creating some endpoints that will interact with my client. And the third point will be just writing a simple frontend in React, which I already know.

My first HTTP requests in Go

I've found this article from Abu Ashraf Masnun which clearly explains how to create simple GET, POST and other types of HTTP requests.
With that knowledge I can try interacting with the RegioJet API for the first time. There is their public api documentation.

The main.go file is our app entrypoint for now. When running go run main.go locations.go, the func main() is called. We call there GetCountries exported from locations.go which will be explained later. And then I loop over each country in returned countries and print their code.

main.go

package main

import (
    "fmt"
    "log"
)

func main() {
    log.Println("Running RegioJet API client")

    var countries = GetCountries()

    for _, country := range countries {
        fmt.Println(country.Code)
    }
}

Later in location.go are defined location structs (Country, City, Station) according to the RegioJet models. The supercool thing about parsing json in golang is that you can define structs and then use json.Unmarshall(data []byte, v interface{}) error to parse the json. I find is super useful, because the result is already typed and you immidiately know what you are working with. (I'm not used to this since I work primarily with Python and Javascript, where both of them are loosely typed languages)

locations.go

package main

import (
    "encoding/json"
    "io/ioutil"
    "log"
    "net/http"
)

var endpointUrl = "https://brn-ybus-pubapi.sa.cz/restapi/consts/locations"

type Station struct {
    ID                 string `json:"id"`
    Name               string `json:"name"`
    Fullname           string `json:"fullname"`
    Aliases            string `json:"aliases"`
    Address            string `json:"address"`
    StationTypes       string `json:"stationTypes"`
    IataCode           string `json:"iataCode"`
    StationURL         string `json:"stationUrl"`
    WheelChairPlatform string `json:"wheelChairPlatform"`
    Significance       string `json:"significance"`
}

type City struct {
    ID            string    `json:"id"`
    Name          string    `json:"name"`
    Aliases       []string  `json:"aliases"`
    StationsTypes []string  `json:"stationTypes"`
    Stations      []Station `json:"stations"`
}

type Country struct {
    Country string `json:"country"`
    Code    string `json:"code"`
    Cities  []City `json:"cities"`
}

type Countries []Country

func GetCountries() Countries {
    log.Println("... getting countries")

    resp, err := http.Get(endpointUrl)
    if err != nil {
        log.Fatalln(err)
    }

    defer resp.Body.Close()

    byteBody, err := ioutil.ReadAll(resp.Body)
    if err != nil {
        log.Fatalln(err)
    }

    var countries Countries
    err := json.Unmarshal(byteBody, &countries)
    if err != nil {
        log.Fatalln(err)
    }

    return countries
}

You may notice that I name all struct members explicitly for json even If I'm not supposed to, because it's taken by convention by the struct member name, so for example Country.Code without explicit json:"code" will match code or even cOdE. But I consider naming it this way as good practise and prevention from large refactoring, because all struct members are not dependent on the keys received in the JSON response.

Last but not least, let's run the code I've shown above...

Output:

$ go run locations.go main.go
2019/07/08 22:19:50 Running RegioJet API client
2019/07/08 22:19:50 ... getting countries
DE
BE
CH
LU
HR
IT
FR
UA
HU
AT
UK
CZ
SK
PL
RO
NL

Result is as expected country code per line.

Many new things to learn and many things learned. My first experience with golang was more than pleasing. I thought of it as more C-like language without any knowledge of it. This was really smooth.

I will skip the implementation of other endpoints and directly jump into how I query fetched data and I will try to think about the core functionality like getting free seats and trying to make seat reservation.