Consider a list of predicates for an object and the fact that there is a logical priority of considering them.
This is just an example, so please do not focus on the requirements themselves.
Left side contains a case statement without a case condition and the right side the same logic implemented with if/else.
Which one do you prefer and why?
Here is an alternative (right side) using guard clauses instead of if/else.
Which one do you prefer and why?
What if there are more statuses to take into consideration?
Which one do you prefer and why?
Somehow, for me, the case statement makes more sense when I take into consideration:
• the order in how the conditions are assessed
• it is a bit more open to add more statuses
• I somehow feel a bit uneasy after using 2 guard clauses (or early returns) in a method
But I like also the variant with guard clauses or the if/else.
@igor_alexandrov I know Rubcop has a rule about this which maybe it is on by default? But I was wondering why is that
• • •
Missing some Tweet in this thread? You can try to
force a refresh
I like to apply when possible the test design techniques on real code. Here I reviewed a bit of code from the open source Rails app from @zammadhq and applied a systematic process to extract test cases:
The first step is to extract test conditions that when looking at the code means to indentify what can be tested from the `check_name` method:
You might think - looking at that code that the two "inputs" are first_name and last_name because those are the things we can affect in order to verify if this method works correctly
When learning #Ruby on #Rails, you might learn RSpec or Minitest, know their DSLs and how to use the them to write model, controller, or integration tests.
There is often a gap in learning how to write good test cases. To address this, I am excited to prelaunch a workshop
What does it mean to test a feature or a piece of code?
How do you know that the tests you wrote will actually catch bugs?
How many tests are enough?
I am launching the preview of a workshop that I am creating:
Good Enough Testing for #Ruby Developers
In this works I will focus on the following objectives
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
Ruby is on the rise according to the Stack Overflow Developer Survey 2023! Here are some insights I extracted from survey results:
In the Most Popular Technology section, Ruby's adoption has grown to 6.23% in 2023, up from 6.05% in 2022. For professional developers, it's even higher at 6.94%
However, for those learning to code, Ruby adoption is slower, at 2.55% in 2023, only slightly up from 2.52% in 2022. The good news is that more beginner-friendly content is being created.