Testing
sagikazarmark opened this issue · 14 comments
By default, we use PHPSpec to test our code, but integration tests are written using phpunit.
In php-http/guzzle6-adapter#24 I proposed that we should write phpunit code in the same style as phpspec. Also, namespaceing should also follow phpspec's logic.
However, @egeloen and I planned to rewrite integration tests using behat from the very beginning, so this might only be a temporary improvement.
if we want to benefit from behat, we should start rewriting integration tests to it right away, rather than shuffle around the phpunit code. i am not sure how much behat is going to help here, but i guess we should try and see how well it goes setting up the tests.
What would be the benefit of Behat for our integration tests?
I think it is semantically better. Also, we can test features, not code. Like what @joelwurtz was trying to achieve.
Yes but not really sure if it's worth the work, for me Behat and BDD test are really viable in a functional project / site with other people than developers writing test. However in this, full developer, context it will be a useless layer of complexity over phpunit IMO.
What we could do it's separate the FeatureTest that i have done in a separate repo wich test every adapter / client.
What's the advantage of having those tests in a separate repository?
Because there are not tests, but just something that check if a client / adapter is able to do something (but not required)
a suite of functional tests would be interesting. we did that for PHPCR with https://github.com/phpcr/phpcr-api-tests/. each implementation can require-dev that repository and include the tests in its phpunit.xml. in the PHPCR case we built a system to let the implementation skip some tests. here we could do sections for testing sync requests and async requests.
i think it makes sense to keep that separate from the contract repository as it can take a considerable size (though PHPCR is way more complex than HTTPlug)
the tricky bit will be setting up a web server that generates all the expected responses. we could inspire ourselves from the functional tests in FOSHttpCache for that. providing the demo things and a webserver script for travis would again be a job for the integration test repo.
in my idea, the tests could for example make sure that http status is not causing an exception, that redirects are not followed by the bare adapter and so on. async could test with a request that sleeps for 5 seconds that we really return before the response is received.
the tests will help having consistent clients and adapters.
For the test server there is already httpbin.org which is a good start and which is used for functional detection
Yes, but it's written in perl or python? We can't install it with composer, that's why I wanted to port it to PHP.
I would prefer to provide a docker image for that ( for local testing) or if you don't want to bother with that use the real site.
I come here as I'm the one who have written the functional tests. I have give a try to httpbin.org when writing them and it does not cover as much as cases we cover in our test suite. Some HTTP verb is not supported as well as not being able to control the timeout... This is why I end up with my own web server for testing.
Hm, docker image sounds like a good idea. 😄
@egeloen yeah, I remember something. Thanks for reminding the exact details.
as nothing happened here for 2 years, should we close this issue?