yordisprieto
Testing Only Code and Dead-Code Elimination
Something I really appreciate from our ecosystem is that we trying to include “Test Support” files as part of the dependency packages.
Recently I have had a dilemma,
- Create two packages (a normal package, and a testing package) and publish them independently, for example:
one_piece_commandedandone_piece_commanded_testing. - Check for
Mix.env()at compile-time and more the code
if Mix.env() == "test" do
defmodule MyPackage.TestSupport do
def hello do
:hello_world
end
end
end
The first idea, is way too much work maintaining the packages. Incrementally becoming worst over time the more packages I have to maintain and whatnot.
The second idea, I feel dirty even suggesting it but I am not sure of any other solution that wouldn’t compile into production code that was only meant to be used in testing. Increasing the binary side (ideally, shouldn’t be the case).
Ideally, Elixir would help in the subject matter somehow, not sure what it would look like.
Any thoughts on the topic? How do you deal with the situation?
P.S: Kind of related to the trick of doing if Code.ensure_loaded?(Absinthe) do: .... to load extra code or not based on deps being installed.
Most Liked
LostKobrakai
oban is not the only library doing that. The same applies to Plug.Test, Phoenix.ConnTest or Phoenix.LiveViewTest.
If test helpers are not meant to be bundled in prod code I’d consider a compile time config like config :my_app, compile_test_helpers: false to disable them. Every other toggle will be a heuristic and therefore just waiting to not work for some user.
Generally I’d really consider hard, why including test helpers in prod code would be problematic though. What if the usecase is a test runner and prod actually runs tests?
LostKobrakai
Imo the issue here is the assumption that test helpers are code only used in tests. For a library I don’t think that’s an assumption, that should be made and therefore I actually support the existing approaches of having those modules be handled just like any other.
There are some valid concerns like file size bloat, but those are optimizations and also likely most relevant in really constraint environments, where you’d have the same concern not only about modules holding test helpers, but rather any module. So for the file size concern it makes sense to use a wholistic approach of dealing with it, rather than thinking about those handful of modules specific to test helpers.
Last Post!
yordisprieto
To be clear, that wouldn’t work after; Mix.env() inside a dependency for a given app since to always be :prod
That is out of the equation and must be done differently
Popular in Discussions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #hex









