Best practice to test glue implementation.

Robson
Robson Posts: 15 🧑🏻‍🚀 - Cadet
in Spryker Development

Is there a spryker recommendation how to test my custom glue implementation with codception maybe?

Answers

  • Hidran Arias
    Hidran Arias Senior Technical Trainer Sprykee Posts: 86 🏛 - Council (mod)

    Have you taken a look at one of the core API module ?

    Here is an example of CustomerApi testing:

    https://github.com/spryker/customer-api/tree/master/tests/SprykerTest/Zed/CustomerApi

  • Robson
    Robson Posts: 15 🧑🏻‍🚀 - Cadet

    Will have a look.

  • benjamin.reuter
    benjamin.reuter Senior PHP Developer Posts: 3 🧑🏻‍🚀 - Cadet
    https://commercequest.space/discussion/comment/28578#Comment_28578

    Are you serious about this?
    I am sorry, but this is a good example of bad testing. What kind of tests are these supposed to be? Are these feature tests?

    Why is there no typing in these tests (or in the package in general)?
    You could for example remove the first assertion completely if you'd just add proper typing.

    What is the first test supposed to be testing? I am known for being too lazy to write long names, but test names should reflect what they're supposed to test. This doesn't even include the name of the tested method "getCustomer". A better name would be something like "testCustomerCanBeRetrievedById".

    After checking the content of that test, I still don't know what it is actually testing. It checks that the result has a non-empty ID and then it has an array in the "data" property that has a non-empty value for the key "CustomerApiTransfer::CUSTOMER_REFERENCE".

    Why should it have these? And shouldn't I care more about the actual result that will be returned? Right now that test would succeed if it would just return a random ApiItemTransfer, as long as it has any value for the ID and array with a key "CustomerApiTransfer::CUSTOMER_REFERENCE" within the data attribute.

    I could write a lot more about the other tests as well, but I think I made my point.

    With tests like this, you get code coverage. But not actual value.

    Looking at the original question again I also don't see the relation to API testing.

    There I would expect something like

    ```

    $response = $I→asCustomer($customerId)→visit($route);

    ```

  • Hidran Arias
    Hidran Arias Senior Technical Trainer Sprykee Posts: 86 🏛 - Council (mod)

    Sorry for the misunderstanding!

    That was just a folder to show you the structure of the testing folder when testing the different layers with codecept.

    As for your last example>
    All tested Glue modules are located at project level in https://github.com/spryker-shop/b2c-demo-shop/tree/master/tests/PyzTest/Glue

    I'll forward your observations to the Core team.

    Thanks!

  • benjamin.reuter
    benjamin.reuter Senior PHP Developer Posts: 3 🧑🏻‍🚀 - Cadet

    Thank you for your understanding :)

    I hope my answer wasn't too harsh.

    One of my passions is providing and advocating good test coverage and I am very often in discussions with other developers who then use bad examples in other repositories to defend their own bad tests.
    So I'm a bit allergic to examples like these being used as guidance.

    But I think the original question still stands;
    Do you have any good examples for API tests in Spryker?
    Right now we're mainly struggling with the authentication which we currently can't properly set or circumvent in our tests.

    Our only working prototype-test so far required real credentials to our OAuth provider, which - apart from being very slow - is no approach we want to take.

Categories