# When the queue contains x messages 
# only mocks the API response 
# Testing how the API behaves with a full queue are defined in the API 

Feature: Can the adapter receive messages?
  The adapter poll method works as expected

  Scenario: No messages are received successfully if the queue is empty
    Given valid config
    When the adapter instance is created
    When the auth method is called
    When a mock receive API response is configured to return 0 messages
    When the poll method is called
    Then a successful response is returned with 0 messages  

  Scenario: 2 messages are received successfully if the queue contains 2 messages
    Given valid config
    When the adapter instance is created
    When the auth method is called
    When a mock receive API response is configured to return 2 messages 
    When the poll method is called
    Then a successful response is returned with 2 messages
    Then the protocol "validate" method is called 2 times
    Then the protocol "decode" method is called 2 times

  Scenario: 10 messages are received successfully if the queue contains 10 messages
    Given valid config
    When the adapter instance is created
    When the auth method is called
    When a mock receive API response is configured to return 10 messages 
    When the poll method is called
    Then a successful response is returned with 10 messages
    Then the protocol "validate" method is called 10 times
    Then the protocol "decode" method is called 10 times

  Scenario: An invalid token returns a forbidden response 
    Given valid config 
    When the adapter instance is created 
    When the auth method is called 
    When a mock receive API response is configured to return a 403 error
    When the poll method is called 
    Then an error response is returned with status 403

  Scenario: On 403 the message is retried once with new credentials 
    Given valid config 
    When the adapter instance is created 
    When the auth method is called 
    When a mock receive API response is configured to return a 403 error 
    When the poll method is called 
    Then an error response is returned with status 403 
    Then the credentials are deleted
    Then the poll method was called with is_retry on
    Then the getAuthorizationHeader method is called 
    
  Scenario: On a retried 403 the message is not retried again
    Given valid config 
    When the adapter instance is created 
    When the auth method is called 
    When a mock receive API response is configured to return a 403 error 
    When the poll method is called with is_retry on
    Then an error response is returned with status 403
    Then the credentials are deleted 
    Then the poll method is not called again

  Scenario: On 503 the message is retried once with the same credentials 
    Given valid config 
    When the adapter instance is created 
    When the auth method is called 
    When a mock receive API response is configured to return a 503 error 
    When the poll method is called 
    Then an error response is returned with status 503 
    Then the credentials are not deleted
    Then the poll method was called with is_retry on
    Then the getAuthorizationHeader method is not called again 
    
  Scenario: On a retried 503 the message is not retried again
    Given valid config 
    When the adapter instance is created 
    When the auth method is called 
    When a mock receive API response is configured to return a 503 error 
    When the poll method is called with is_retry on
    Then an error response is returned with status 503
    Then the credentials are not deleted 
    Then the poll method is not called again