Chapter 7: Testing Your Application (157)
    Before I start I wanted to update an issue that you might have had while using the pure code that I posted, While trying to access the artists page for any artists you might have had an issue that you couldn't see the page without an error, this was because I added in an extra param that shouldn't have been there within the tunez/lib/tunez_web/live/artists/show_live.ex 
        def render(assigns) do
            # ...
            <.button_link navigate={~p"/artists/#{@artist.id}/albums/new"} kind="primary"
                :if={Tunez.Music.can_create_album?(@current_user)}> # Remove @artist
                New Album
            </.button_link>
    This should solve that issue.

    There are 2 main reasons to test your code:
        To confirm our current understanding of the code.
        To protect against untended code changes.
        
    For this we will use ExUnit to test in Elixir

    What Should We Test?
        The Basic First Test
            We will start with this simple test. 
                describe "Tunez.Music.read_artists!/0-2" do
                    @tag :skip
                    test "when there is no data, nothing is returned" do
                        assert Music.read_artists!() == []
                    end
                end

    Setting Up Data
        For these test we will need some data to test against. So for this we will need to create some data. There is 2 ways of doing this:
            Setting up test data using your resource actions
            Seeding data directly via the data layer, bypassing actions

        Using Actions to Set Up Test Data
            We will use actions to start and these will be considered a series of events to create an artist etc. tunez/test/music/artists_test.exs
                describe "Tunez.Music.search_artists!/1-3" do
                    test "can find artists by partial name match" do
                        artist =
                            Tunez.Music.create_artist!(
                            %{
                                name: "The Froody Dudes",
                                biography: "42 musicians all playing the same instrument (a towel)"
                            },
                            authorize?: false
                            )

                        assert %{results: [match]} = Tunez.Music.search_artists!("Frood")
                        assert match.id == artist.id
                    end
                end

            As we can see here we are creating an artist and then doing the search to make sure that its in the DB. Let's talk about some pros and cons for this.

            "Pro: We Are Testing Real Sequences of Events"
                If we change anything in the way that we are doing the creating or updating how a user will create this will fail, so we can see exactly how a user might see the results.

            "Con: Real Application Code Has Rule and Dependencies"
                There might be a reason to only make a test on Tuesdays (Weird but that might really be a thing) this test will fail. There are workarounds but it might not always be perfect for this. Here is some syntax that might solve that issue.
                    create :create do
                        argument :validate_tuesday, :boolean, default: true, public?: false
                        validate IsTuesday, where: argument_equals(:validate_tuesday, true)
                    end
            
            "Pro: Your Application is End-to-End Testable"  
                This can be the best so long as you are able to ensure that you have the right steps enabled to work around the quirks of your current setup

        Seeding Data
            Seeds can be used to make any or a lot of user data and artists so that you can do some tests on the data created. AshPostgres can essentially perform an INSERT. There might be a error that we want to have at least 3 sentences, We can even use AshPostgres to insert things that might not hold to the current version of what we want or choice to validate. lib/tunez/mu 
                # The validation for needing 3 sentences might look like
                validations do
                    validate {SentenceCount, field: :biography, min: 3} do
                        where changing(:biography)
                    end
                end
            
            Let's write a test for this.
                # Demonstration test only - this validation doesn't exist in Tunez!
                describe "Tunez.Music.update_artist!/1-3" do
                test "when an artist's name is updated, the biography length does
                                        not cause a validation error" do
                artist =
                    Ash.Seed.seed!(%Tunez.Music.Artist{
                    name: "The Froody Dudes",
                    biography: "42 musicians all playing the same instrument (a towel)."
                    })

                updated_artist = Tunez.Music.update_artist!(artist, %{name: "New Name"})
                assert updated_artist.name == "New Name"
                end
            end

            "Pro: Your Tests Are Faster and Simpler"
                This can work to set everything that you have in the exact scenario that you are trying to test. 

            "Con: Your Tests Are Not as Realistic"
                This might not be the exact way that a user will be able to interact with the db or the UI

        How do I choose Between Seeds and Calling Actions?
            When both will do what you need, consider what you’re trying to test. Are you testing a data condition, such as the validation example, or are you testing an event, such as running a search query? If the former, then use seeds. If the latter, use your resource actions. When in doubt, use actions.

    Consolidating Test Setup Logic
        Ash.Generator provides tools for dynamically for generating. It is built off of the StreamData. Let's try it out with an IEX session.
            iex -S mix
            ex(1)> Ash.Type.generator(:integer, min: 1, max: 100)
            #StreamData<66.1229758/2 in StreamData.integer/1>
            iex(2)> Ash.Type.generator(:integer, min: 1, max: 100) |> Enum.take(10)
            [21, 79, 33, 16, 15, 95, 53, 27, 69, 31]

        It can even do more with maps see below.
            iex(1)> Ash.Type.generator(:map, fields: [
                    hello: [
                        type: {:array, :integer},
                        constraints: [min_length: 2, items: [min: -1000, max: 1000]]
                    ],
                    world: [type: :uuid]
                ]) |> Enum.take(1)
            [%{hello: [-98, 290], world: "2368cc8d-c5b6-46d8-97ab-1fe1d9e5178c"}]

        Creating Test Data Using Ash.Generator
            There is already set some of these set in the file tunez/test/support/generator.ex, just un comment the lines that is already there. And then remove the raise line. Once that is done we can use that generator. Head back to the file tunez/test/tunez/music/artist_test.exs
                # Demonstration test - this is only to show how to call generators!
                defmodule Tunez.Accounts.UserTest do
                    import Tunez.Generator

                    test "can create user records" do
                        # Generate a user with all default data
                        user = generate(user())
                        # Or generate more than one user, with some specific data
                        two_admins = generate_many(user(role: :admin), 2)
                    end
                end

            This way we will create a new artists for each instance of the entires there is a way to make sure that we only create a new user for each one with the once/2 helper. You would use it like this.
                def artist(opts \\ []) do
                    actor = opts[:actor] || once(:default_actor, fn ->
                        generate(user(role: :admin))
                    end)         
                    changeset_generator(
                        Tunez.Music.Artist,
                        :create,
                        defaults: [name: sequence(:artist_name, &"Artist #{&1}")],
                        actor: actor,
                        overrides: opts
                    )
                end

            There is even a way to put this all together with both albums and artists, there is also a way to seed the data with seed_generator seeded_artists generator.
                def artist(opts \\ []) do
                    actor =
                    opts[:actor] ||
                        once(:default_actor, fn ->
                        generate(user(role: :admin))
                        end)

                    changeset_generator(
                    Tunez.Music.Artist,
                    :create,
                    defaults: [name: sequence(:artist_name, &"Artist #{&1}")],
                    actor: actor,
                    overrides: opts
                    )
                end

                def album(opts \\ []) do
                    actor =
                    opts[:actor] ||
                        once(:default_actor, fn ->
                        generate(user(role: opts[:actor_role] || :editor))
                        end)

                    artist_id =
                    opts[:artist_id] ||
                        once(:default_artist_id, fn ->
                        generate(artist()).id
                        end)

                    changeset_generator(
                    Tunez.Music.Album,
                    :create,
                    defaults: [
                        name: sequence(:album_name, &"Album #{&1}"),
                        year_released: StreamData.integer(1951..2024),
                        artist_id: artist_id,
                        cover_image_url: nil
                    ],
                    overrides: opts,
                    actor: actor
                    )
                end

                # This is for when you want to seed the data not just 
                def seeded_artist(opts \\ []) do
                    actor =
                    opts[:actor] ||
                        once(:default_actor, fn ->
                        generate(user(role: :admin))
                        end)

                    seed_generator(
                    %Tunez.Music.Artist{name: sequence(:artist_name, &"Artist #{&1}")},
                    actor: actor,
                    overrides: opts
                    )
                end
    Testing Resources
        Testing Actions
            The tests should follow a few guidelines:
                Prefer to use code interfaces when calling actions
                Use the raising "bang" versions of code
                Avoid Pattern matching to assert the success of failure
                For asserting errors, use Ash.Test.assert_has_error or assert_false
                Test policies, calculations, aggregates, and relationships separately

            Lets set some more test that will work with the search functions.
                describe "Tunez.Music.search_artists/1-2" do
                    defp names(page), do: Enum.map(page.results, & &1.name)

                    test "can filter by partial name matches" do
                        ["hello", "goodbye", "what?"]
                        |> Enum.each(&generate(artist(name: &1)))

                        assert Enum.sort(names(Music.search_artists!("o"))) == ["goodbye", "hello"]
                        assert names(Music.search_artists!("oo")) == ["goodbye"]
                        assert names(Music.search_artists!("he")) == ["hello"]
                    end

                    test "can sort by number of album releases" do
                        generate(artist(name: "two", album_count: 2))
                        generate(artist(name: "none"))
                        generate(artist(name: "one", album_count: 1))
                        generate(artist(name: "three", album_count: 3))

                        actual =
                            names(Music.search_artists!("", query: [sort_input: "-album_count"]))

                        assert actual == ["three", "two", "one", "none"]
                    end
                end

        Testing Errors
            tunez/test/tunez/music/album_test.exs
                describe "Tunez.Music.create_album/1-2" do
                    test "year_released must be between 1950 and next year" do
                    admin = generate(user(role: :admin))
                    artist = generate(artist())
                    # The assertion isn't really needed here, but we want to signal to
                    # our future selves that this is part of the test, not the setup.
                    assert %{artist_id: artist.id, name: "test 2024", year_released: 2024}
                            |> Music.create_album!(actor: admin)

                    # Using `assert_raise`
                    assert_raise Ash.Error.Invalid, ~r/must be between 1950 and next year/, fn ->
                        %{artist_id: artist.id, name: "test 1925", year_released: 1925}
                        |> Music.create_album!(actor: admin)
                    end

                    # Using `assert_has_error` - note the lack of bang to return the error
                    %{artist_id: artist.id, name: "test 1950", year_released: 1950}
                    |> Music.create_album(actor: admin)
                    |> Ash.Test.assert_has_error(Ash.Error.Invalid, fn error ->
                        match?(%{message: "must be between 1950 and next year"}, error)
                    end)
                end
        
        Testing Policies
            There is a way to test even policies, the Ash.can? is the way again. tunez/test/tunez/music/artist_test.exs
                describe "Music.can_create_artist?/1" do
                    test "only admins can create artists" do
                    admin = generate(user(role: :admin))
                    assert Music.can_create_artist?(admin)
                    editor = generate(user(role: :editor))
                    refute Music.can_create_artist?(editor)
                    user = generate(user())
                    refute Music.can_create_artist?(user)
                    refute Music.can_create_artist?(nil)
                end
            end

            Lets say that you want to add a new requirement that a user should be able to look up their own records and that admins should be able to look up any record. 
                policy action(:get_by_email) do
                    authorize_if expr(id == ^actor(:id))
                    authorize_if actor_attribute_equals(:role, :admin)
                end

            Now we can test this functionality.
                # Demonstration tests only - this functionality doesn't exist in Tunez!
                test "users can only read themselves" do
                    [actor, other] = generate_many(user(), 2)
                    # this assertion would fail, because the actor *can* run the action
                    # but it *wouldn't* return the other user record
                    # refute Accounts.can_get_user_by_email?(actor, other.email)
                    assert Accounts.can_get_user_by_email?(actor, actor.email, data: actor)
                    refute Accounts.can_get_user_by_email?(actor, other.email, data: other)
                end

                test "admins can read all users" do
                    [user1, user2] = generate_many(user(), 2)
                    admin = generate(user(role: :admin))
                    assert Accounts.can_get_user_by_email?(admin, user1.email, data: user1)
                    assert Accounts.can_get_user_by_email?(admin, user2.email, data: user2)
                end

            Testing Relationships and Aggregates
                There is nothing that is needed to test Relationships or aggregates as they can just be done at any time. The thing that we can do right now is show the way you can use authorize?: false to skip the authorization. That way you can test what you want after you have tested the polices, again one at a time.
                    # Demonstration test only - this functionality doesn't exist in Tunez
                    test "users cannot see who created an album" do
                        user = generate(user())
                        album = generate(album())
                        # We *can* load the user record if we skip authorization
                        assert Ash.load!(album, :created_by, authorize?: false).created_by
                        # If this assertion fails, we know that it must be due to authorization
                        assert Ash.load!(album, :created_by, actor: user).created_by
                    end
            
            Testing Calculations
                One thing to test is the aggregates that we created so for this one we will add in a temp calculation head to tunez/lib/tunez/music/artists.ex
                    calculations do
                        calculate :name_length, :integer, expr(string_length(name))
                    end

                Then we can test it in an iex session. 
                    iex(1)> artist = %Tunez.Music.Artist{name: "Amazing!"} |>
                                    Ash.load!(:name_length)
                    #Tunez.Music.Artist<...>
                    iex(2)> artist.name_length
                    8
                    iex(30)> Ash.calculate!(Tunez.Music.Artist, :name_length,
                                    refs: %{name: "Amazing!"})
                    8

                We can then even use this for calculations that require the database. We can rewrite that same function using the PostgreSQL's length function:
                    calculations do
                        calculate :name_length, :integer, expr(fragment("length(?)", name))
                    end

                Then we can call it in an iex session:
                    iex(3)> Ash.calculate!(Tunez.Music.Artist, :name_length,
                                        refs: %{name: "Amazing!"})
                    SELECT (length($1))::bigint FROM (VALUES(1)) AS f0 ["Amazing!"]
                    8

                We can also define a code interface with define_calculation, They take in a tuple and then can use the syntax to call them later. lib/tunez/music.ex
                    resource Tunez.Music.Artist do
                        ...
                        define_calculation :artist_name_length, calculation: :name_length,
                        args: [{:ref, :name}]
                    end

                Then we can test with
                    # Demonstration test only - this function doesn't exist in Tunez!
                    test "name_length shows how many characters are in the name" do
                        assert Tunez.Music.artist_name_length!("fred") == 4
                        assert Tunez.Music.artist_name_length!("wat") == 3
                    end
                
            Unit Testing Changesets, Queries, and Other Ash Modules
                # Demonstration test only - this is covered by action tests in Tunez
                test "year_released must be greater than 1950" do
                    Album
                    |> Ash.Changeset.for_create(:create, %{year_released: 1920})
                    |> assert_has_error(fn error ->
                        match?(%{message: "must be between 1950 and" <> _}, error)
                    end)
                end

                # Demonstration test only - this is covered by action tests in Tunez
                # This won't work for logic in hook functions - only code in a change body
                test "previous_names store the current name when changing to a new name" do
                    changeset =
                        %Artist{name: "george", previous_names: ["fred"]}
                        |> Ash.Changeset.new()
                        # `opts` and `context` aren't used by this change, so we can
                        # leave them empty
                        |> Tunez.Music.Changes.UpdatePreviousNames.change([], %{})

                    assert Ash.Changeset.changing_attribute?(changeset, :previous_names)
                    assert {:ok, ["george", "fred"]} = Ash.Changeset.fetch_change(changeset,
                        :previous_names)

            Should I Actually Unit Test Every Single One of These Things?
                Variations needs there own test and anything that you want to be sure that you want to make sure will always work you should test.

    Testing Interfaces
        Everything so far has been about resources or actions, but there will be needs to test the interface. So that you know that a user will have the same experience.

        Testing GraphQL
            Since AshGraphql is built on top of the excellent absinthe library, we can use its great utilities22 for testing. It offers three different approaches for testing either resolvers, documents, or HTTP requests.

        Testing AshJsonApi
            Everything we previously said for testing a GraphQL API applies to testing an API built with AshJsonApi as well. Since we generate an OpenAPI specification for your API, you can even use the same strategy for guarding against breaking changes.

        Testing Phoenix LiveView
            Testing user interfaces is entirely different than anything else that we’ve discussed thus far. There are whole books dedicated solely to this topic. LiveView itself has many testing utilities, and often when testing LiveView, we’re testing much more than the functionality of our application core.

    Fixing "pg-trgm" Error
        ** (Postgrex.Error) ERROR 0A000 (feature_not_supported) extension "pg-trgm" is not available

        hint: The extension must first be installed on the system where PostgreSQL is running.

        Want to figure out why this is not working need to test this for the tunez_test db.