Otherwise it is impossible to dynamically remove them,
which partially defeats the point of adding them dynamically
in the first place.
Therefore this commit moves the whole dynamic backend
management to the user.
Closes#8213
It was printing this when running: mix test --only foo
Including tags: [:foo]
Excluding tags: [:test]
which is deceiving beucase the order end up rendering useless the include filter.
Swaps the order then.
Additionally swaps the order in ExUnit.Formatter.format_filters/2 and tests,
while not necessary, maintaining the order is a good thing when it's something related
to precedence.
Fixes issues mentioned in #8335, particularly in this discussion:
https://github.com/elixir-lang/elixir/pull/8335#pullrequestreview-168148010
Tests should be first excluded, then included, and then skipped (if any left).
The only exception to the rule is when we explicitly include tests with :skip filter,
to which the :ok value is returned.
Check for line ending in output messages in ex_unit_tests.exs and beginning of line when applicable. This makes sure we check for the full line,
avoiding unexpected results appearing at the end of the line. Related discussion:
https://github.com/elixir-lang/elixir/pull/8312#discussion_r226867015
Remove on_exit_reload_config/0 and replace it with configure_and_reload_on_exit/1
This adds the --max-failures flag to `mix test` task.
When N number of failures is reached, the suite will
be aborted, and return a the total number of tests
finished upto that moment, along with the failures.
If a module is invalid, all its tests are counted as
as failure even though they are reported as invalid.
Type is now no longer a reserved key in ExUnit, and we're now
documenting that `:test_type` is a key that is automatically set
by ExUnit, but that it is available for users to override if they would
like.
Sometimes if we were calculating the diff for two lists, one of which
was a subset or superset of the other, then we wouldn't give a very
helpful diff. This makes sure that for subsets and supersets, we give
the best possible diff.
Erlang/OTP 20 warns if the stacktrace is read outside of a
catch/rescue. This commit mirrors this behaviour by consistently
warning on `System.stacktrace/0` being used outside of a
catch/rescue.
Erlang/OTP 21 warns whenever System.stacktrace/:erlang.get_stacktrace
are used. Therefore we need to promote the usage of `__STACKTRACE__`
and make sure to conditionally compile it according to the OTP version.
This requires changes to the Exception normalization mechanism
so we compute `__STACKTRACE__` only when strictly required.
In future Elixir releases, `System.stacktrace/0` will warn when
used even inside catch/rescue.