These are chat archives for Behat/Behat

22nd
Aug 2017
bluebaroncanada
@bluebaroncanada
Aug 22 2017 02:50
I have a scenario like so
  Scenario: The user can authorize
    Given there is an existing access token "mytoken"
    And the expiration is 100000 milliseconds in the future
    When the provided access token is "mytoken"
    Then authorization should succeed
The problem is that I need to do step one and two before saving to the database.
So how would I do that?>
Hedoux Tony
@TonyHedoux_twitter
Aug 22 2017 09:52
Hello here. Currently preparing a migration from PHP 5.6 (32 bits) to PHP 7.x (64 bits) for a set of Behat 2.5.3 projects. Should I be careful with something particular to Behat?
SamyOteroGlez
@SamyOteroGlez
Aug 22 2017 11:52
@bluebaroncanada I am guessing you have some sort of logic to generate the token, to check if the token exist and is available to grant access and to remove the token availability. In the scenario you described above, you want to test if the there is a token already generated in the db and is available then grant the access, just that. So you could within the Before scenario hook, manually create the token and trigger only the logic that check if the token exist and is available to grant access. I think the scenario could be rewrited to:
  Scenario: The user can authorize
    Given there is valid token
    When I access the system using the valid token
    Then The authorization should succeed
@bluebaroncanada On the other hand, if you want to test the expiration time of the token then you can write another scenario just for that, or even create another to test the behavior when the token has expired, etc.
@bluebaroncanada You just need to keep things simple and easy.
Bit Wombat
@bitwombat
Aug 22 2017 12:30
I would think, rather then use the Before scenario hook, just generate the token in the Given step... really like the clarity of that rewrite!
Bit Wombat
@bitwombat
Aug 22 2017 12:36
One of my favorite guidelines I've learned recently about code (and probably scenarios) is that they should be organized to be so simple that someone reading it says "yeah, of course, obviously".
bluebaroncanada
@bluebaroncanada
Aug 22 2017 12:55
@bitwombat I don't like this because it doesn't provide the granularity that I desire. My token is a complex object and has different logic based on its many states.
SamyOteroGlez
@SamyOteroGlez
Aug 22 2017 15:35
@bluebaroncanada Well then you just need to write an scenario to test each of those states. The point is been as simple as possible. An scenario should be testing only one thing. If that works then you can test the next one. For example, if the function verifyToken() is dependant on generateToken(), then you write a test for generateToken() if the test pass, the you can write a test for verifyToken() assuming that generateToken() will work as expected. In the end at some point you will be running all the tests and if the generateToken() test fails then the other one should fail too or at least have a different behaviour. It is easy to debug your tests, if something fail and the test is simple the you know where to look and what update/modify.