What type of Spec to use for Rails 6, RSpec 4, on an API only app.

[Gregory Leepart]

Hello.  Long time reader, first time postr.

I've been out of the RoR game for 3 years and am back in full on.  I'm upgraded my stack to the latest and greatest.  

• Rails 6.0.1.3
• Ruby 2.7.1p83
• devise (4.7.2)
  
• rspec-rails (4.0.1)
  
• factory_bot_rails (6.0.0)
  

I've been using the following tutorial to get me back up to speed.   http://apionrails.icalialabs.com/book/chapter_five  It's an amazing tutorial, but unfortunately it is very outdated, but I've been able to trouble shoot most of the issues.

I've been working on the Controller spec tests, but from reading the benefits of rspec-rails, rails, etc, I thought it prudent to bite the bullet and start using Request Specs.  (based on this link)

From there I found out I should be using Feature Specs, and now finally system specs.

So I'm supposed to write system specs, but that requires Capybara, and further reading states:

By default, system tests are run with the Selenium driver, using the Chrome browser, and a screen size of 1400x1400. The next section explains how to change the default settings.
The Capybara gem is automatically required, and Rails includes it in generated application Gemfiles. Configure a webserver (e.g.Capybara.server = :webrick) before attempting to use system specs.

I don't need a browser, or the over head. What I'm hoping is someone can tell me what's the proper Spec to use to test the API only project and if I could see an example of proper type of spec that would test the Users_Controller (but NOT with 'type: :controller' as it should be 'type: :request' at a minimum, 'type: :feature' most likely and maybe even 'type: :system' if there's a valid reason to use Cabybara on a API only app.

Thanks in advance for you time and effort.  My apologies on my post, I'll have to learn how to use the formatting better to make it more readable.

G

[Jon Rowe]

Hello!

Welcome back to the Ruby community!

There seems to be a bit of confusion in your post, which hopefully I can clarify.

The parts of Rails testing stack we used for controller specs was deprecated by the Rails team due to being “only part of the story” of a request, they were an incomplete part of the controller request life cycle and so were never really unit tests, you can still use them with the addition of the `rails-controller-tests` gem but the suggested replacement is request specs.

A request spec runs the entire rack stack so can be entirely Ruby based, but offers a realistic insight into the full request life cycle as an integration test.

This sounds like what you want for testing your API.

System tests (and thus specs) are an end to end testing solution, allowing testing of browsers and Javascript against your web server of choice, but equally, you could choose to use to have a complete acceptance style test. Where you send full on JSON to the web server and have it passed to Rails. Wether the extra boot time is enough to discourage you from this for the extra gain is up to you.

Additionally, although capybara is used to talk HTML to rails in tests, you still have access to the raw `rack-test` helpers to send JSON or params etc.

So the two things are different, and can still be used together, or not, as you decide.

Hope that helps!

Cheers

Jon Rowe

---------------------------

ma...@jonrowe.co.uk

jonrowe.co.uk

On 28 June 2020 at 21:38, Gregory Leepart wrote:

Hello.  Long time reader, first time postr.

I've been out of the RoR game for 3 years and am back in full on.  I'm upgraded my stack to the latest and greatest.  

• Rails 6.0.1.3
• Ruby 2.7.1p83
• devise (4.7.2)
• rspec-rails (4.0.1)
• factory_bot_rails (6.0.0)

I've been using the following tutorial to get me back up to speed.   http://apionrails.icalialabs.com/book/chapter_five  It's an amazing tutorial, but unfortunately it is very outdated, but I've been able to trouble shoot most of the issues.

I've been working on the Controller spec tests, but from reading the benefits of rspec-rails, rails, etc, I thought it prudent to bite the bullet and start using Request Specs.  (based on this link)

From there I found out I should be using Feature Specs, and now finally system specs.

So I'm supposed to write system specs, but that requires Capybara, and further reading states:

[Gregory Leepart]

Thanks Jon,

You're right, I did sound confusing, and was very tired when I wrote that but wanted to get out what I could before I forgot what I 'thought' I knew.

You were very clear and even doing a little more research I see that yes, request specs are the way to go.  There are not a lot of examples of them, given controller specs still work and are very similar.

Thanks again!  Nice to post on a forum and get a knowledgeable response!

Greg

[Jon Rowe]

Hello again, 

You are correct, controller specs and request specs are very similar. So most controller spec examples will work fine as request specs.

The difference is that request specs will go through the entire rack middleware stack (which is what the request handling in Rails is made out of) meaning that you must have routes and be authenticated etc as per a normal request. This is what most people tend to want anyway.

Chers

Jon Rowe

---------------------------

ma...@jonrowe.co.uk

jonrowe.co.uk