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 On Monday, June 29, 2020 at 1:40:01 AM UTC-7, Jon Rowe wrote: > > 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 > --------------------------- > [email protected] <javascript:> > 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 > <http://rspec.info/blog/2016/07/rspec-3-5-has-been-released/> 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: > > > 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 > > -- You received this message because you are subscribed to the Google Groups "rspec" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/rspec/7849e86d-0d17-4225-842a-fe6096694cc1o%40googlegroups.com.
