Mox

Mox는 동시성 있는 목(mock) 설계를 위한 Elixir 라이브러리입니다.

테스트 용이한 코드 작성하기

테스트 용이한 코드 작성하기

테스트와 테스트를 용이하게 해주는 목(mock)은 일반적으로 어떤 언어에서도 주목받는 하이라이트가 아닙니다. 그래서 비교적 덜 다뤄지는 것도 별로 놀랄 일은 아니죠. 하지만, Elixir에서는 확실히 목을 사용할 수 있습니다! 정확한 사용 방법은 다른 언어에서 익숙한 방식과 다를 수 있지만 궁극적인 목표는 동일합니다. 그것은 바로 목은 내부 함수의 출력을 흉내 낼 수 있어 코드에서 가능한 모든 실행 경로를 확인할 수 있다는 것입니다.

더 복잡한 사용 사례에 들어가기 전에, 코드를 테스트하기 더 쉽게 만들어주는 몇 가지 기법을 이야기해 보죠. 간단한 전략은 함수 안에서 하드코딩된 모듈을 사용하는 대신 모듈을 함수 인자로 넘기는 것입니다.

예를 들어 다음처럼 함수 안에 하드코딩된 HTTP client가 있다고 해봅시다.

def get_username(username) do
  HTTPoison.get("https://elixirschool.com/users/#{username}")
end

이렇게 하는 대신 다음처럼 HTTP client를 인자로 넘길 수 있습니다.

def get_username(username, http_client) do
  http_client.get("https://elixirschool.com/users/#{username}")
end

혹은 apply/3 함수를 사용해도 됩니다.

def get_username(username, http_client) do
  apply(http_client, :get, ["https://elixirschool.com/users/#{username}"])
end

모듈을 인자로 전달하면 관심사를 분리하는 데 도움이 됩니다. 객체 지향 개념의 장황함이란 함정에 빠지지 않도록 주의한다면 이러한 제어의 역전을 의존성 주입으로 이해 해봐도 괜찮습니다. get_username/2 함수를 테스트하려면 검증에 필요한 값들을 반환하는 get 함수가 있는 모듈을 전달만 하면 됩니다.

이 구조는 매우 단순하여 대상 함수가 접근이 쉬운 경우에만 유용합니다(즉 내부 어딘가에 숨겨진 private 함수를 테스트하기엔 어렵습니다).

좀 더 유연한 전략은 애플리케이션 설정(configuration)을 이용해야 합니다. 전혀 알아차리지 못했을 수도 있지만 사실 엘릭서 애플리케이션은 설정에 자신의 상태를 유지합니다. 따라서 모듈을 하드코딩하거나 함수 인자로 넘기지 않고 다음처럼 애플리케이션 config에서 읽어오게 할 수 있습니다.

def get_username(username) do
  http_client().get("https://elixirschool.com/users/#{username}")
end

defp http_client do
  Application.get_env(:my_app, :http_client)
end

그런 다음 config 파일에는 다음과 같이 적습니다.

config :my_app, :http_client, HTTPoison

이 구조, 그리고 애플리케이션 config에 대한 의존성은 앞으로 나올 모든 내용의 기초가 됩니다.

혹시 조금 깊게 생각하시는 분들을 위해 잠깐 짚고 넘어가자면, 물론 http_client/0 함수를 생략하고 Application.get_env/2를 직접 호출해도 됩니다. 또한 Application.get_env/3에 세 번째 인자를 기본값으로 넣고도 동일한 결과를 얻습니다.

애플리케이션 config를 활용하면 각 환경마다 특정 구현을 가질 수 있습니다. 이를테면 dev 환경에서는 샌드박스 모듈을 참조하고 test 환경에서는 인메모리 모듈을 사용하는 식입니다.

하지만 환경당 하나의 고정된 모듈만 갖는 건 충분히 유연하지 않습니다. 함수가 사용되는 방식에 따라 모든 가능한 실행 경로를 테스트하기 위해 서로 다른 응답들이 필요할 수 있죠. 사람들 대부분이 잘 모르는 사실은 애플리케이션 설정이 런타임에 변경 가능하다는 것입니다! Application.put_env/4을 한번 읽어 보세요.

HTTP 요청의 성공 여부에 따라 애플리케이션이 다르게 동작해야 한다고 해 봅시다. get/1 함수가 각각 있는 여러 모듈을 만듭니다. 한 모듈은 :ok 튜플, 다른 모듈은 :error 튜플을 반환합니다. 그런 다음 Application.put_env/4을 사용해 get_username/1 함수 호출 전에 설정을 준비합니다. 테스트 모듈은 다음과 같을 것입니다.

# Don't do this!
defmodule MyAppTest do
  use ExUnit.Case

  setup do
    http_client = Application.get_env(:my_app, :http_client)
    on_exit(
      fn ->
        Application.put_env(:my_app, :http_client, http_client)
      end
    )
  end

  test ":ok on 200" do
    Application.put_env(:my_app, :http_client, HTTP200Mock)
    assert {:ok, _} = MyModule.get_username("twinkie")
  end

  test ":error on 404" do
    Application.put_env(:my_app, :http_client, HTTP404Mock)
    assert {:error, _} = MyModule.get_username("does-not-exist")
  end
end

필요한 모듈들(HTTP200Mock과 HTTP404Mock)은 생성되었다고 가정합니다. on_exit 콜백을 setup 픽스쳐에 추가하여 각 테스트가 끝날때마다 :http_client가 이전의 상태로 돌아가도록 했습니다.

하지만 일반적으로 위와 같은 패턴을 따라야 하는건 아닙니다! 다음과 같은 몇가지 이유가 있는데, 당장은 그 이유들이 와닿지 않을 수도 있습니다.

우선 :http_client에 대해 정의한 모듈이 필요한 작업을 수행할 수 있다는 보장이 없습니다. 즉 모듈에 get/1 함수가 반드시 있어야 한다는 규약이 강제되지 않습니다.

두 번째로, 위 테스트는 비동기로 안전하게 실행될 수 없습니다. 애플리케이션의 상태는 애플리케이션 전체_로 공유되기 때문에, 한 테스트에서 :http_client를 재정의하면 다른 (동시에 실행되는)테스트가 잘못된 결과를 받을 수도 있습니다. 테스트가 _평소에는 통과하는데 때때로 무작위로 실패하는 경우 이런 문제가 있는지 봐야 합니다. 주의하세요!

마지막으로 이 접근법은 결국 애플리케이션을 목 모듈 더미 투성이로 지저분하게 만듭니다.

위 구조를 소개한 이유는 진짜 솔루션이 작동하는 방식을 직관적으로 간략히 설명하여 이해를 돕고자 함입니다.

Mox : 이 모든 문제들의 해결책

Elixir에서 목을 사용할 때 믿고 쓰는 패키지는 José Valim이 직접 만든 Mox입니다. 위에서 나열한 모든 문제들을 해결해 줍니다.

전제 조건을 기억하세요. 다음 코드처럼 설정된 모듈을 가져오기 위해 애플리케이션 config를 확인해야만 합니다.

def get_username(username) do
  http_client().get("https://elixirschool.com/users/#{username}")
end

defp http_client do
  Application.get_env(:my_app, :http_client)
end

그리고 mox를 의존성 목록에 포함시켜야 합니다.

# mix.exs
defp deps do
  [
    # ...
    {:mox, "~> 0.5.2", only: :test}
  ]
end

mix deps.get으로 패키지를 설치합니다.

이제, test_helper.exs 파일을 다음 2가지를 하도록 수정합니다.

하나 이상의 목을 정의해야 합니다.
애플리케이션 config에 목을 설정해야 합니다.

# test_helper.exs
ExUnit.start()

# 1. 동적으로 목 정의 
Mox.defmock(HTTPoison.BaseMock, for: HTTPoison.Base)
# ... etc...

# 2. 컨피그 설정값 재정의 (config/test.exs 에 추가한 것과 유사함)
Application.put_env(:my_app, :http_client, HTTPoison.BaseMock)
# ... etc...

Mox.defmock에 대해 주의해야 할 몇 가지 중요한 사항이 있습니다. 먼저 왼쪽편의 이름은 임의로 넣습니다. Elixir의 모듈 이름은 아톰일 뿐이라, 모듈을 굳이 생성하지 않고 목 모듈의 이름을 “예약” 해 두는 것입니다. 보이지 않는 곳에서 Mox는 BEAM 안에 이 이름을 가진 목을 즉석에서 생성할 것입니다.

두 번째 유의할 점은 for:에서 참조하는 모듈이 반드시 비헤이비어(behaviour)여야 한다는 점, 즉 반드시 콜백들을 정의해야 한다는 뜻입니다. Mox가 이 모듈을 인트로스펙션으로 사용하므로 @callback 이 정의된 목 함수들만 정의 가능하죠. 이것이 Mox가 규약을 강제하는 방식입니다. 비헤이비어 모듈을 찾는 것이 어려울 때도 있습니다. 예를 들어 HTTPoison같은 경우 HTTPosion.Base이 비헤이비어지만 소스 코드를 까보지 않으면 이 같은 사실을 알기 힘듭니다. 어떤 라이브러리에 대한 목을 만들려고 하는데 해당 라이브러리엔 비헤이비어가 없을 수도 있습니다! 이러한 경우 직접 규약(contract)을 정의하고 그것을 충족하는 비헤이비어와 콜백들을 정의해야 할 것입니다.

이것은 중요한 요점을 시사하는데, 바로 추상화 계층(일명 indirection)을 사용하여 라이브러리 패키지에 직접적으로 의존하는 대신 직접 작성한 모듈이 그 패키지를 사용하도록 하는 게 좋다는 점입니다. 잘 만들어진 애플리케이션이 적절한 “바운더리”를 정의하는 건 중요하지만 목의 메커니즘은 바뀌지 않았다는 점을 주의하세요.

마지막으로 테스트모듈에서 Mox를 import하여 :verify_on_exit! 함수를 호출합니다. 그럼 이제 expect 함수를 호출하여 목 모듈의 출력값을 자유롭게 정의합니다.

defmodule MyAppTest do
  use ExUnit.Case, async: true
  # 1. Import Mox
  import Mox
  # 2. setup fixtures
  setup :verify_on_exit!

  test ":ok on 200" do
    expect(HTTPoison.BaseMock, :get, fn _ -> {:ok, "What a guy!"} end)

    assert {:ok, _} = MyModule.get_username("twinkie")
  end

  test ":error on 404" do
    expect(HTTPoison.BaseMock, :get, fn _ -> {:error, "Sorry!"} end)
    assert {:error, _} = MyModule.get_username("does-not-exist")
  end
end

각 테스트에 대해 동일한 목 모듈(여기서는 HTTPoison.BaseMock)을 참조하고 expect 함수를 사용하여 호출된 각 함수의 출력값을 정의합니다.

Mox는 안전하게 비동기 테스트에 쓸 수 있고 각 목이 정해진 규약을 따르도록 합니다. 이 목들은 실제와 다를 바 없어 모듈들을 정의해서 애플리케이션을 어수선하게 만들지 않아도 됩니다.

Elixir의 목 세계에 오신 것을 환영합니다!

강의에 실수가 있거나 기여하고 싶은 부분이 있으신가요? GitHub에서 이 강의를 수정해보세요!