marick

marick

I have written a description of one way to allow complex structures to change without breaking a lot of client code and tests. It describes the use of one package you can add to Mix dependencies, plus two modules you can copy and tweak. I show the beginning of the writeup below. The whole thing is at Stubbing Complex Structures. Around 300 lines, including code samples.


Sometimes, despite what you might want, you end up with a complex structure – sometimes called a “God object” – that’s used in many places in your code. If that client code contains text like user.privileges[:author].read, you have two problems:

  1. Any attempt to change the “shape” of the complex structure becomes hard because there are so many places to change. That locks you into complexity because it’s too painful to undo it by, for example, breaking the single structure into several.

  2. Tests have to construct sample data. In a dynamically typed language, they don’t have to create a complete God object; they need only supply the fields the code under test actually uses. But, once again, changes to the structure can require a lot of changes to tests.

Here, I’ll show how to avoid such coupling, using the code in MockeryExtras.Getters and MockeryExtras.Given. The emphasis is on both simplifying change and avoiding busywork.

Look in the example directory for working code to adapt.

TL;DR

Make getters

defmodule Example.RunningExample do
  import MockeryExtras.Getters
  
  defstruct [:example, :history]

  getters :example, [
    eens: [], field_checks: %{}
  ]
  getters :example, :metadata, [
    :name, :workflow_name, :repo, :module_under_test
  ]

Use getters - tersely and stubbably - in client code:

defmodule Example.Steps do
  use Example.From

  def assert_valid_changeset(running, which_changeset) do 
    from(running, use: [:name, :workflow_name])                 # <<<<
    from_history(running, changeset: which_changeset)           # <<<<
    # `name = RunningExample.name(running)`, etc. is too wordy

    do_something_with(name, workflow_name, changeset)
  end

The above requires copying and slightly tweaking code in Example.From.

Don’t build structures, stub getters

defmodule Example.StepsTest do
  ... 
  import Example.RunningStubs

  setup do # overridable defaults
    stub [name: :example, workflow_name: :success]
    :ok
  end

  test "..." do 
    stub(field_checks: %{name: "Bossie"}, ...)
    stub_history(inserted_value: ...)
    ...
    assert ...
end

The above requires copying and slightly tweaking code in Example.RunningStubs.

Where Next? Top

Trending in Guides/Tuts Top

krasenyp
You probably already know that &lt;span&gt;{nil}&lt;/span&gt; in a HEEX template produces &lt;span&gt; &lt;/span&gt; when rendered. I fin...
New

Other Trending Topics Top

garrison
Hobbes is a low-level distributed database for the Elixir programming language. Hobbes provides a simple, safe, and scalable storage lay...
New
mcass19
ExRatatui lets you cook up rich terminal UIs in Elixir, powered by Rust’s ratatui via Rustler NIFs. Build interactive terminal applicatio...
New
Damirados
Hello everyone. After busy few months I am happy to announce v0.1.0 of Emerge &amp; Solve. They are GUI (Emerge) and State management (S...
New
netoum
Corex is an accessible, unstyled UI component library for Phoenix that integrates Zag.js state machines using Vanilla JavaScript and Live...
New
wintermeyer
There are three potential reasons for members of this forum to have a look at https://vutuv.de You are tired or annoyed of LinkedIn. Yo...
New
webofbits
Aludel - LLM Evaluation Workbench Aludel is an embeddable Phoenix LiveView dashboard for evaluating and comparing LLM prompts across mult...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews