How to use jason @derive in test?


defmodule LibJasonTest do
  use ExUnit.Case

  defmodule Category do
    @type t :: %__MODULE__{
            id: Integer.t(),
            name: String.t()

    @derive Jason.Encoder
    defstruct [:id, :name]

  defmodule Book do
    @type t :: %__MODULE__{
            id: Integer.t(),
            name: String.t(),
            price: Float.t(),
            categories: [Category.t()],
            created_at: DateTime.t()

    @derive Jason.Encoder
    defstruct [

  test "encode / decode" do
    book = %Book{}


error info

  1) test encode / decode (LibJasonTest)
     ** (Protocol.UndefinedError) protocol Jason.Encoder not implemented
 for %LibJasonTest.Book{id: nil, name: nil, price: nil, categories: nil,
 created_at: nil} of type LibJasonTest.Book (a struct), Jason.Encoder pr
otocol must always be explicitly implemented.

     If you own the struct, you can derive the implementation specifying
 which fields should be encoded to JSON:

         @derive {Jason.Encoder, only: [....]}
         defstruct ...

     It is also possible to encode all fields, although this should be u
sed carefully to avoid accidentally leaking private information when new
 fields are added:

         @derive Jason.Encoder
         defstruct ...

     Finally, if you don't own the struct you want to encode to JSON, yo
u may use Protocol.derive/3 placed outside of any module:

         Protocol.derive(Jason.Encoder, NameOfTheStruct, only: [...])   
         Protocol.derive(Jason.Encoder, NameOfTheStruct)
     . This protocol is implemented for the following type(s): Any, Atom
, BitString, Date, DateTime, Decimal, Float, Integer, Jason.Fragment, Ja
son.OrderedObject, List, Map, NaiveDateTime, Time
     code: dbg(Jason.encode!(book))
       (jason 1.4.1) lib/jason.ex:164: Jason.encode!/2
       test/lib_jason_test.exs:36: (test)

Finished in 0.1 seconds (0.00s async, 0.1s sync)
1 test, 1 failure

As an optimization, protocols in Elixir go through a compile-time process called consolidation, which has the “drawback” of making it impossible to add new protocol implementations at runtime. Because tests are dynamically evaluated, they live in that “runtime” category.

You can read about consolidation here. It has a note about implementing protocols in tests and offers two possible fixes, one of which is to just disable protocol consolidation in tests.


thanks, very helpful :wink: