Idea: Innovation or absurdity regarding phoenix testing

Hi everyone,

I had the following idea regarding testing, after I read more on EX Unit docs and also work with it a bit.

Would it be possible to use decorators to create the tests inside the actual file like this?

Here is a schema:

defmodule Phx.Accounts.User do
  use Ecto.Schema
  import Ecto.Changeset

  schema "users" do
    field :name
    field :email
    field :age, :integer
  end

  def changeset(user, params \\ %{}) do
    user
    |> cast(params, [:name, :email, :age])
    |> validate_required([:name, :email])
    |> validate_format(:email, ~r/@/)
    |> validate_inclusion(:age, 18..100)
    |> unique_constraint(:email)
  end
end

And here we have a context for User

defmodule Phx.Accounts do
  import Ecto.Query, warn: false
  alias Phx.Repo

  alias Phxl.Accounts.User
  @doc
  """
     Below is my proposition of testing in the same file
     @list_users = multiple_users with this code we tell phoenix that we want a list of multiple_users if false 
     complain and fail test

  """
  @list_users = multiple_users

  def list_users do
    Repo.all(User)
  end
  @doc
  """
     Below is my proposition of testing in the same file
     @user = insert_user_one_valid with this code we tell phoenix that we want a single user inserted if the 
    changeset is true if false complain and fail test
  """
@user = insert_user_one_valid
  def insert_user(attrs, %{}) do
      %User{}
      |> User.changeset(attrs)
      |> repo.insert()
  end
end


UPDATE thanks to @yourpalal for clarification reasons
Instead of this

describe "User.registration_changeset/2" do
  @invalid_attrs %{}

  test "changeset with invalid attributes" do
    changeset = User.registration_changeset(%User{}, @invalid_attrs)

    refute changeset.valid?
  end

USE THIS

  @doc
  """
     Below is my proposition of testing in the same file
     @user = insert_user_one_valid with this code we tell phoenix that we want a single user inserted if the 
    changeset is true if false complain and fail test
  """
@user = insert_user_one_valid
  def insert_user(attrs, %{}) do
      %User{}
      |> User.changeset(attrs)
      |> repo.insert()
  end
end


Before i end this proposition, I want to say that if this kind of testing will be created and adopted. Every user will create tests because it will actually be fun and easy.
What do you think about this idea?

Thanks in advanced for any opinions suggestions and criticism

This sounds like the doctests which are already available in elixir. If that’s what you’re looking for, then the good news is it already exists and you can start using it right now :slight_smile:

If that’s not what you want then I think it might be good to show how your idea differs from that.

4 Likes

As mentionned, it’s already included. If You start a fresh project, You will have the hello world of doctests.

  @doc """
  Hello world.

  ## Examples

      iex> Demo.hello()
      :world

  """
  def hello do
    :world
  end
2 Likes

OK then why does the rest of tests exist?
Also why do many developers don’t test their applications when they reach a certain point in size?

Because from my point of view this needs to change the testing should be included with the actual app not separated, It should be within the code you write to make your application work.

Thanks for heads up about the doc test

With doctests, You test functions directly in the code, within documentation. That’s why code is highly documented.

ExUnit allows more complex tests…

2 Likes

Why are those tests necessary?

Because i feel like I am writing another application altogether when testing everything.

Thanks for the responses so far

It’s optional, You don’t need to write tests if You don’t want :slight_smile:

OK optional, although i suspect they do have a role, why then other companies love TDD development of an app.

It’s very personal… some people don’t like to test. It has been largely debated.

Joe Armstrong was not too much into tests, nor docs.

4 Likes

Thanks @kokolegorille
I will read it thoroughly maybe i will get some light on this matter form the link you provided.
Because now I am in the dark

I did not start that thread because I do not like testing. I have a big problem with fads.

I am sorry if I misunderstood, but from some of your previous posts, I felt You had strong opinion against some current testing practices :slight_smile:

Is it important why other companies love TDD? I think it’s important to find a good way of working. Maybe Turing award winners like Leslie Lamport and Donald Knuth can give better advice than TDD/XP/agile promotors. But see the thread kokolegorille posted.

1 Like

A strong opinion against fads (TDD/XP/agile) yes. Not against testing.

4 Likes

Can You please tell me what fads means? I am not a native english speaker.

(Kokogorille is Dutch). Zoiets als een rage.
See the word in context here:

http://www.budiu.info/blog/lamport.html

1 Like

Wasn’t it more that you are an enthousiastic TDD practioner that felt offended in that thread?

is a gross simplification and incorrect

Hi,

I read the thread and the following conclusions emerged:

  • TDD will no solve your real problem
  • Testing should be done after you have an application
  • But what test should you choose and what part of the application should need to be tested? The database operations the controller the model or all

Please correct me if i am wrong or have misunderstood the ideas in the thread @StefanHoutzager

Also if you have time can you suggest a good method for someone new to phoenix absinthe and elixir to test their app?
Found this https://securityboulevard.com/2019/10/wormwood-an-explicit-way-to-test-absinthe-graphql-apis/ but don’t know it is good or tested by the community

If others would like to share their ideas experiences on this subject, please do so. Any opinion is welcomed.
Thanks in advanced for any suggestions

My 2 cents.

It all depends on what you are doing. For example if I‘m building a prototype for my own project and I try out different approaches - I don‘t write tests until my approach is stable. When it is, I will write tests to make sure I don‘t break it. How much functionality is covered depends on the complexity. For my own projects I trust myself more, and my testing is more relaxed.

Completely different story at work where the team is big, people have different skills and projects need to be built with maintenance in mind. Good tests there are very high priority.

4 Likes

Can you explain more on what you mean by good tests?

Also even if you build projects for yourself doesn’t maintenance play a big role?