Introduction to RSpec: Explain Why One `expect` Clause per Test Case

[ZackHoang]

Checks

• This is not a duplicate of an existing issue (please have a look through our open issues list to make sure)
• I have thoroughly read and understand The Odin Project Contributing Guide
• Would you like to work on this issue?

Describe your suggestion

This section of this lesson talks about how each test case should only have one expect clause per test case.

Write your expectation using expect. The expect method is also chained with .to for positive expectations, or .to_not/.not_to for negative expectations. We prefer .not_to. Also, limit one expect clause per test case.

I understand that while Ruby is very opinionated, I was wondering if this is actually the case for every Ruby project there is. While this is a very small detail, I'm worried that this phrase might convince learners to split their test cases thinner than needed. I also did a quick Google and on a quick glance, I did not find any result talking about how Rspec only expect one expect clause per test case.

For context, I mostly followed the Node path after being stuck on the Ruby path for a while so I might not be seeing the entire picture but the Node path did not ask learners that there should only be one assertion per test case at all.

I even found an article on Stackoverflow talking about how devs should not limit their assertions to one test case each.

I think we should either remove this section entirely, or add a small paragraph talking about how one should structure their assertions around their tests.

Path

Ruby / Rails

Lesson Url

https://www.theodinproject.com/lessons/ruby-introduction-to-rspec

(Optional) Discord Name

No response

(Optional) Additional Comments

No response

[rlmoser99]

I think this depends on the type of testing we are talking about. Unit tests are cheap/fast and should only have one expect clause per test case, which is the type of tests this lesson covers.
https://www.betterspecs.org/#single

If we taught integration testing, this would not apply. Integration tests interact with the database and are more expensive (time-consuming) to run, so you can have multiple assertions (though typically with an aggregate_failures block so the other assertions continue to run after one fails).
https://rspec.info/features/3-13/rspec-core/expectation-framework-integration/aggregating-failures/

[ZackHoang]

@rlmoser99 Fair point, so should we specify that only applies for unit testing?

[rlmoser99]

@ZackHoang I think we would need to re-frame the entire lesson, because in looking at the lesson we are not saying that we are teaching you unit testing, but there are other types of testing. Mentioning that only using one expect is for unit testing, but not other types of testing seems to open a can of worms.

Do you have a suggestion on the best way to handle this?

[ZackHoang]

@rlmoser99 The best fix I could come up with right now is just not talk about how many expects per test cases should be used and provide Better Specs in the assignment section as a guideline for learners to follow. Like you said, we are not teaching learners about unit testing specifcally, just the practice of TDD using RSpec. I don't see anywhere in this lesson talks about how it is only teaching unit testing but not other types of tests so deleting that should suffice.

Better Specs is one resource I think could be really helpful especially for Ruby learners because how it directly talks about Ruby so it seems pretty easy to follow and it's not a whole lot of content. I think it's one that could carry great all the way throughout the Ruby and the Rails course.

[rlmoser99]

@ZackHoang Thanks for this open dialogue. However, the more I think about this, I am not sure removing this vital concept about unit testing is the right move.

Even though we don't mention that we are teaching unit testing, we actually are teaching unit testing and it goes hand in hand with TDD. We focus on unit testing because around 70-80% of a RSpec test suite should be unit tests.

So I actually think it would be better to think about re-framing our lesson(s) by introducing this language in these lessons.

Right now BetterSpecs is in the Additional Resources, but I do think this resource would be a great assignment, rather then just an AR that people can skip.

[ZackHoang]

@rlmoser99 I see your point, how about we mention that we will only be focusing on unit testing this lesson and leave other type of testing for learners to find out? I'm still not sure myself either about whether or not if we should keep the "one expect per test case" phrase and I'm still on the side of deleting that, even though it is a common rule when it comes to unit testing.