pierrelegall
Explicit vs DRY tests
Hello alchemists!
![]()
Tests are supposed to be readable/maintainable as every code should be in a perfect world. And explicitness is a good thing for readability.
Beginning my “one kata per day”, I wrote FizzBuzz tests in two ways. I don’t really know which style I prefer: one is very explicit and less concise. The other one is more in a DRY style.
What’s your opinion about this? ![]()
Version 1:
defmodule Kata.FizzBuzz.Test do
use ExUnit.Case
import Kata.FizzBuzz
test "1, 2, 4, 7, 8 returns number as a string" do
assert fizz_buzz(1) == "1"
assert fizz_buzz(2) == "2"
assert fizz_buzz(4) == "4"
assert fizz_buzz(7) == "7"
assert fizz_buzz(8) == "8"
end
test "3, 6, 9, 12 returns Fizz" do
assert fizz_buzz(3) == "Fizz"
assert fizz_buzz(6) == "Fizz"
assert fizz_buzz(9) == "Fizz"
assert fizz_buzz(12) == "Fizz"
end
test "5, 10, 20, 25 returns Buzz" do
assert fizz_buzz(5) == "Buzz"
assert fizz_buzz(10) == "Buzz"
assert fizz_buzz(20) == "Buzz"
assert fizz_buzz(25) == "Buzz"
end
test "15, 30, 45, 60 returns FizzBuzz" do
assert fizz_buzz(15) == "FizzBuzz"
assert fizz_buzz(30) == "FizzBuzz"
assert fizz_buzz(45) == "FizzBuzz"
assert fizz_buzz(60) == "FizzBuzz"
end
end
Version 2:
defmodule Kata.FizzBuzz.Test do
use ExUnit.Case
import Kata.FizzBuzz
test "1, 2, 4, 7, 8 returns number as a string" do
[1, 2, 4, 7, 8]
|> Enum.each(fn n -> assert fizz_buzz(n) == "#{n}" end)
end
test "3, 6, 9, 12 returns Fizz" do
[3, 6, 9, 12]
|> Enum.each(fn n -> assert fizz_buzz(n) == "Fizz" end)
end
test "5, 10, 20, 25 returns Buzz" do
[5, 10, 20, 25]
|> Enum.each(fn n -> assert fizz_buzz(n) == "Buzz" end)
end
test "15, 30, 45, 60 returns FizzBuzz" do
[15, 30, 45, 60]
|> Enum.each(fn n -> assert fizz_buzz(n) == "FizzBuzz" end)
end
end
Most Liked
hauleth
My approach, as your is IMHO too repeating the implementation:
defmodule Kata.FizzBuzzTest do
use ExUnit.Case
use ExUnitProperties
property "multiples of 3 contains `Fizz`" do
check all n <- integer() do
result = fizz_buzz(n * 3)
assert String.contains?(result, "Fizz")
end
end
property "multiples of 5 contains `Buzz`" do
check all n <- integer() do
result = fizz_buzz(n * 5)
assert String.contains?(result, "Buzz")
end
end
property "returned value is a binary" do
check all n <- integer() do
assert is_binary(fizz_buzz(n))
end
end
property "result for 'plain' values is stringified integer" do
check all n <- integer(), rem(n, 3) * rem(n, 5) != 0 do
assert fizz_buzz(n) == Integer.to_string(n)
end
end
end
There probably could be some additional properties like the above
tfwright
I think I am an outlier when it comes to tests, but I would not include any logic to generate assertions in unit tests. I would just choose one type of input for each type of output, with a test for each. If this logic was extra critical or issues keep popping up with unexpected inputs, I guess I would consider adding some sort of property based test to supplement the unit tests, but I would consider carefully before doing it.
LostKobrakai
To me the test labels also stand out the most. They should at best specify what needs to happen and not just repeat the examples.
At that point property testing (e.g. using stream_data) might become the more appropriate tool to use.
Last Post!
jarmo
I always prefer explicit tests. Yes, they are more tedious to write, but much easier to understand when they start to fail.
Also, if trying to keep tests as DRY as production code then at one point they might get so complex that they need their own tests.
Popular in Discussions
Other popular topics
Chat & Discussions>Discussions
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
- #hex
- #security










