Thread by @lucianghinda

So let's talk about #testing and #Ruby and specifically about test design.

I think this could be a good conversation to sparkle so I am going to start sharing more about what I think about testing with some focus on Ruby and Ruby on Rails.

I will start with testing guidelines

I think it is important when speaking about tests to think about 3 situations a developer can be when dealing with tests:

1️⃣ Verify requirements/document how it works

That is when writing the feature code and want to verify either (a) requirements and/or (b) document how it works.

2️⃣ When changing the existing logic
When you have a change request and you have to change the code and adapt the tests.

3️⃣ When debugging
When time passes, and you have a bug and want to fix it. The details of both the code and test are fuzzy and there can be time pressure

Taking these in consideration when thinking about a set of rules for writing tests, I would recommend to keep in mind the following:

Choose rules that will help with all situations but the importance is:
First make debugging easy
Then make changing easy
Then make verifying requirements easy

When writing the code for the feature, you have all the context loaded in your head.

You might work for a couple of days on that, so it does not seem to matter how you name your tests, where you place the preconditions, or how you set up the system's state.

The risk is that you will try to write smart code in tests and DRY them out.

You should think about how you organise your tests so that when you read one single test, it should be easy to understand.

Optimise for the case where you are trying to grep and find the test that is executing a behavior you are debugging. Or you are just seeing a test fail after fixing a bug and so you are opening that file to the line where that test is and you try to understand it.