taluu / behapi Goto Github PK

Add some tests. :}

The README is not enough. Or is it ? :P

It is a source of bug with the autowiring (cf Behat/Behat#1080), and also I'm not quite sure it is necessary to support it out of the box. It would also simplify all the stuff like a lot.

Using instead an extension or something along those lines would be better IMO.

This would mean a refactoring of things and how the request is handled though.

Or I could keep using http-plug / psr-17/ psr-18 things, and see on the discoverable clients how to integrate symfony client (I'd rather do that actually).

So many sexy things in it (helper container <3), and also a bunch of deprecated stuff to remove...

Currently migrating our project on PHP 8.0, will behapi natively support it soon ?

Thank you

Support form data support for the "parameters" (will probably though another step than the current "parameter" query).

Would be a really nice feature if we could generate code coverage using phpunit code coverage tool :

https://github.com/sebastianbergmann/php-code-coverage

But from my understanding, since we are hitting the API from an external process, we cannot get proper code coverage through xdebug ? Is there a way around that ?

Because it is more maintained than the webmozart (it's a fork of webmozart actually)

As discussed, we have to use the tag @api to use --api-debug and the @debug tag.

Baptiste Clavié [6:18 PM] 
je voulais avoir genre soit `@rest` soit `@api`

[6:18]  
mais je pense que je vais opter pour `@rest`

[6:18]  
(parce que `DebugRest`)

[6:18]  
ou alors `DebugApi`

[6:19]  
voir `DebugHttp` en fait, ca devrait avoir plus de sens

Remy Gazelot [6:19 PM] 
+1

Baptiste Clavié [6:20 PM] 
du coup faudrait que j'introduise un tag `@http` (edited)

Implement JSONPath support for json context (see https://github.com/SoftCreatR/JSONPath)

To push a bit further would be to support "switching" the fetching of the data from the Json.

This will allow us to require only the strict minimum and not the whole phpunit ecosystem just to use their asserts

The psrs were released in last july, so maybe it'd be time to use this in Behapi.

But that maybe would introduce bc breaks, so it will be for 0.13 (or 1.0 ?)

The content-type header is harcoded here https://github.com/Taluu/behat-api/blob/master/context/Rest.php#L45

I think you should remove it because for some requests (GET for example) there is no body, so no content-type and all rest api doesn't have a json content-type. This info should be set for each requests or find a way via an abstract method or configuration to set this value by the lib integrator

Instead of forcing a format (eg through behapi: { debug: { formatter: 'pretty' } } ), we should use the current printer to print the data correctly, so that it works for all outputs.

Add a README (How tos, where does this project comes from, .... etc)

Because Guzzle4 (Guzzle3 ??) is old. And why bother with Guzzle when we could open more things.

We currently have a lot of duplications for Request and Response dumpers for the var-dumper (one for basic, one for json).

This may need to change.

https://github.com/coduo/php-matcher

I like the exemple to match a whole json object against a match. But it should be an optionnal dependency IMO (like Twig is).

Currently, only not-namespaced twig classes are supported (Twig_Environement and not Twig\Environment). Need to fix that... maybe.

Maybe, because I doubt that namespaced twig classes are used, especially as they are only aliases extending the original twig classes.

Adding an event dispatcher could be useful, if we need to (e.g) add some headers, ... and so on, rather than having to listen to a @BeforeStep which may not be quite efficient.

Firing some events here and there could be useful.

https://github.com/Taluu/Behapi/blob/master/src/Extension/Behapi.php#L42

From line 42 to 45

Currently using the debug mode with --api-debug nor @debug does not works as expected.
The debug context is loaded via behat.yml

default:                                                                         
  formatters:                                                                    
    progress: true                                                               
  suites:                                                                        
    main:                                                                        
      paths: [%paths.base%/features/specs]                                       
      services: "@behapi.container"                                              
                                                                                 
      contexts:                                                                  
        - Behapi\Context\Rest:                                                   
          - "@http.client"                                                       
          - "@http.stream_factory"                                               
          - "@http.message_factory"                                              
          - "@http.history"                                                      
                                                                                 
        - Behapi\Context\Json:                                                   
          - "@http.history"                                                      
                                                                                 
        - Behapi\Context\DebugRest:                                              
          - "@debug"                                                             
          - "@http.history"                                                      
                                                                                 
  extensions:                                                                    
    Behapi\Extension\Behapi:                                                     
      base_url: 'http://nginx/app_dev.php'  

But the output seems not good:

/srv $  ./vendor/bin/behat features/specs/api/decoder.feature:18 --api-debug 
@rest
Feature: Test data request decoder using a debug endoint
  In order to test the data decoder
  As a api user
  I need to be able to send data

  Scenario: send json data via GET should be ignored        # features/specs/api/decoder.feature:18
    When I create a "GET" request to "/debug/api/echo-data" # Behapi\Context\Rest::createARequest()
    And I set the following body:                           # Behapi\Context\Rest::setTheBody()
      """
       {"foo": "bar"}
      """
    And I send the request                                  # Behapi\Context\Rest::sendRequest()
    Then the status code should be 200                      # Behapi\Context\Rest::statusCodeShouldBe()
    And the response should be a valid json response        # Behapi\Context\Json::responseIsValidjson()
    And in the json, "data.foo" should be equal to "bar"    # Behapi\Context\Json::theJsonPathShouldBeEqualTo()
      PropertyAccessor requires a graph of objects or arrays to operate on, but it found type "NULL" while trying to traverse path "data.foo" at property "foo". (Symfony\Component\PropertyAccess\Exception\UnexpectedTypeException)

--- Failed scenarios:

    features/specs/api/decoder.feature:18

1 scenario (1 failed)
6 steps (5 passed, 1 failed)
0m0.14s (9.17Mb)

The ->getRaw() call should not be on the result of the getValue call, but on the PyString value