No implicit conversion of HTTParty::Response into String (TypeError) in Ruby

Question

I'm creating a user and then querying. But when I pass the id in the query I am getting this error. this was not happening.

my class
  class Crud

include HTTParty
base_uri 'http://dummy.restapiexample.com/api/v1'

def create 
    nome = Faker::UniqueGenerator.clear
    nome = Faker::Name.unique.first_name
    salario = Faker::Number.number(digits: 2)
    idade   = Faker::Number.number(digits: 2)
    $body = {name: nome, salary: salario, age: idade }.to_json
  
  $headers = {
    'Accept' => 'application/vnd.tasksmanager.v2',
    'Content-Type' => 'application/json'
  }

  self.class.post('/create', body: $body, headers: $headers) 
end

def retrieve(id)
  self.class.get("/employee/#{ id }")
 
 
  $response = @manter_user.create
  expect(@manter_user.create.code).to eq (200)
  puts $response.body
  @id = JSON.parse($response)['id']

Answer 1

TL;DR

Since the source for your HTML, CSS, JavaScript, and model/controller weren't provided, it's hard to guess what your real problem is. However, you've given enough information to suggest that you're going about this particular set of tests sub-optimally, and would be better off refactoring the tests or modifying either the login implementation or the user interface to be more testable.

NB: This is a good example of why test-first development is useful. Retrofitting tests onto existing code is harder than making sure the testability is baked in from the beginning!

What to Validate and Where to Validate It

This isn't really a Cucumber outline problem. The issue is most likely with the steps of your test, or underlying UI issues. There's a strong likelihood that you either aren't using unique CSS ID's or other consistent and easy-to-locate information related to your flash messages if the validation is being done server-side, or that you aren't properly driving the web page if you're doing validation in JavaScript and manipulating the DOM to insert your error messages.

Furthermore, the UI itself isn't the ideal place to test anything other than valid or invalid logins. If you want to know why a login is invalid, for security reasons you generally want to do the more granular testing in the model or controller tests if you want to know why a given login failed. You should never return things like "incorrect password" or "invalid username" (as opposed to "invalid login") that leaks information about whether a given account even exists.

Additionally, email validation is generally a waste of time. While there are some very complex regular expressions that come close—see this Perl regex for RFC 822 addresses as an example—email addressing was never designed to conform to regular expression patterns. Furthermore, most people implement email validations badly, and naive validations often won't accept perfectly valid email addresses such as plus-addressing or qmail-style dash extensions. Additionally, even putting in a "valid" email address that matches RFC 822, RFC 5822, or whatever RFC you're trying to validate against can't actually validate that it's a deliverable email anyway.

Given the above, you should most likely just validate that both fields are non-empty before allowing the Sign-In button to be clickable. That seems to be the main check you want to do anyway. Otherwise, just check the page for some invariant "invalid login" text provided by the flash or whatever you're using to manipulate the DOM during text entry or when validating logins.