Elixir unit tests next to the source file

andym

i prefer to have my unit tests next to the source file instead of a separate folder. when i run mix test it runs the tests only within the test folder. if i remove the test folder, move the test files, and the give the following configuration in the mix.exs configuration

      test_paths: ".",
      exclude: "deps",
      test_pattern: "*_test.exs",

then it seems to do something different and fails with the following error

(Protocol.UndefinedError) protocol Enumerable not implemented for "." of type BitString. This protocol is implemented for the following type(s): DBConnection.PrepareStream, DBConnection.Stream, Date.Range, Ecto.Adapters.SQL.Stream, File.Stream, Floki.HTMLTree, Function, GenEvent.Stream, HashDict, HashSet, IO.Stream, Jason.OrderedObject, List, Map, MapSet, Range, Stream, Timex.Interval
    (elixir 1.14.3) lib/enum.ex:1: Enumerable.impl_for!/1
    (elixir 1.14.3) lib/enum.ex:166: Enumerable.reduce/3
    (elixir 1.14.3) lib/enum.ex:4307: Enum.each/2
    (mix 1.14.3) lib/mix/tasks/test.ex:529: Mix.Tasks.Test.do_run/3
    (mix 1.14.3) lib/mix/task.ex:421: anonymous fn/3 in Mix.Task.run_task/4
    (mix 1.14.3) lib/mix/cli.ex:84: Mix.CLI.run_task/2

i also tried using tag filters

  @tag mustexec: true
  test "test1" do
  end

and then running ix test --only mustexec but i still get the same error

8 comments

#unit-testing

0 1813 8

2023-03-03 19:31:19 UTC

Showing Posts 1 to 8

Show Best Posts
Show All (oldest first)
Show All (newest first)

moogle19

test_paths expects a list of path, so ["."] should work. But you need a test_helper.exs file in your project directory then.
Also not sure why you want to break with the convention as it makes it hard for other people to find your test and understand your project.

Post #1

ericdouglas

Maybe it can help you: Test files outside test folder.

Post #2

ericdouglas

Also not sure why you want to break with the convention as it makes it hard for other people to find your test and understand your project.

It is much easier to find the test files in that way since it is colocated with the file containing the implementation.

Ex:

lib/
    module/
        file.ex
        file_test.exs
        another_file.ex

Another advantage is that it becomes super clear which files have tests and which don’t.

Post #3

kanishka

BTW, I am sure you are aware, but doctests help you achieve this to some extent.

Post #4

dimitarvp

Not trying to convince you to drop your idea but a test coverage library will tell you what is and what isn’t tested yet.

Post #5

namxam

I completely agree with you. And I would add another point. Having them next to the module which is tested, has three more advantages:

I use tests as a documentation tool. They are nice code examples and often better transfer meaning than words. When a library does not have extended documentation, but a good test suite, it helps to check it out.
Code / test navigation is much easier, as you do not have to switch between deeply nested folders.
When remove obsolete modules, with colocated tests, you only have two remove 2 files or a folder. No need to search in multiple places.

The only thing which is bugging me, that for integration or e2e tests, you still need a test folder or something similar to it.

Right now, I stay with elixirs / phoenix default structure and put all tests in the test folder. But I would still prefer to have them colocated

Post #6

D4no0

When remove obsolete modules, with colocated tests, you only have two remove 2 files or a folder.

Well not really, do you write only unit tests? While I agree with you that in regard of unit tests for functions in a module this is the case, when doing higher level tests of your system, having the test file linked to a module will not help you much, if at all.

Post #7

sodapopcan

This must be a people who use tree-explorers for navigation versus those who don’t. Any semi-decent modern editor is going to have a “jump to test file and back” hotkey so finding 1:1 tests is a non-issue. I do use a tree-explorer but it’s primarily for getting an overview of module structure so I find it so noisy with file names doubled-up most of the time.

I could bikeshed on this forever so I’ll leave it at that