Gain insights into good testing practices in Ruby on Rails. Learn the testing mindset, convert requirements into user stories, and master feature, request, and unit tests for comprehensive coverage.

bullet3.tar.gz

foo-copy

second

challenge1

requests

unit

requestChallenge

featureChallenge

unitChallenge

PassingT1

This course aims to teach you how to write better Rails applications by applying good testing practices. You’ll learn about the reasoning behind testing and the process of applying good testing practices. 

In the first half of the course, you’ll learn about the testing mindset and understand its importance. Next, you’ll learn to turn business requirements into user stories. These user stories will become the basis of the code and tests you’ll write.

Once you understand the reasoning and process, you’ll proceed to write the actual tests. You’ll test what is most important to the end user first. So, the first set of tests you’ll learn to write will be feature tests. Finally, you’ll learn to write request tests and unit tests ensuring end-to-end coverage of our application.

Bulletproof Ruby on Rails Applications

The type of test we’ve seen so far is called a **happy path** test because all it cares about is the case where everything goes as planned. What about when things aren’t going as planned?


It would be a good idea at this point to rethink the user story mapping session. Take some time to consider what can go wrong with this feature. Put some ideas on paper and discuss them with the stakeholder.
 
In most projects, if we spend enough time brainstorming, we can come up with many edge cases. That’s why it’s a good idea to talk to the stakeholder and decide which edge cases are important enough to consider.



Here are some possible edge cases:

* What happens if the user has a typo in their email address?
* What if their password is too short?

* Do we only care about the first name? Or do we want first and last names?

* What if there’s already a user with that same email in the system?

The list goes on.


# Example
Let’s say we’ve brainstormed the user story mapping and decided that it would be a good idea to ensure that we don’t allow two users with the same email address to register.

## Define a new scenario
Let’s define a new scenario for this case.



Let’s learn how to tackle situations when things don’t go as planned


Before We Start

The Why Behind Testing

The How Behind Testing

Planning

The Feature Layer

The Request Layer

The Unit Layer

Create a Bill Split Application Using Ruby on Rails

Conclusion

When Things Go Wrong