Please help. My team and I, not sure how to handle long test names. We try to keep the lines short, maybe around 80-100 characters, so what is the preferred way to handle long test names?
test “long text description that extends beyond 100 chars” do
3 things that I can think of
- do nothing, let test names extend forever without breaks
- test "long text description that " <>
“extends beyond 100 chars” do
- test “long text description that
extends beyond 100 chars” do
Problem with 1 is when they are hard to read.
Problem with 2 is you have to concatenate every line
Problem with 3 is the name of the test prints out with weird spacing
I can’t think of any great way to handle this particular issue. I’m hoping someone has a solution I have overlooked.
I think it depends. If these are unit tests, generally speaking you should be able to come up with a terse name for what you are testing, but it should also be throughly descriptive of what you are testing. As an example, if you were testing an ecto schema, you may have a couple tests named
"valid changesets" and
"invalid changesets". You would not need to include the name of the schema because it would be inferred from the test module name. You may also want to include the use of the
describe/2 macro to help narrow the scope of your tests down as well. However, every now and then I will have a longer test name that just needs to be longer because of the vocabulary within the project.
If you are doing some larger testing like integration tests, then it is not the worst thing in the world to have longer names because the scope of the test is also much larger.
At the end of the day, if a test fails, I should be able to read it’s name and have some understanding of what failed and where within my codebase.
describe which you might use to specify some common condition of your tests. Only 1 level of
describe allowed though.
describe "when user doesn't exist yet" do
test "creates user" do
test "sends email" do
Typically when I have long test names, it’s because I’m trying to describe preconditions (given), the expected action (when), and/or the result (then). It can sometimes be helpful to call these out and you can use a multiline string to do so. These are similar to what you would do in cucumber without all the boilerplate and mappings.
given the user doesn't exist
when the user registers
then the user is created
|> test do