Sylius: How does Behat tests and profiles work?

Created on 31 Jan 2016  路  8Comments  路  Source: Sylius/Sylius

I've look around any PRs and issues arround tests I could find but I couldn't find answers to these question?! It would be great @pamil or others involved in tests help me here :)

  1. What's up with @ui-* suites? What's their purpose? What do they do? What is the difference between suites/cart.yml and suites/ui-cart.yml?
  2. Now that you've removed javascript profile how does Behat knows that it should run @javascript tagged suites in selenium2 session?
  3. We had a good experience with PageObject design pattern, are you sure it is working well? How sure are you that going this road is a perfect choice?
  4. What is exactly cached in cached profile?
  5. Are classes in Sylius/Behat generic enough to be used by our application and it's tied to SyliusCore?

I've these questions mostly because I'm so new to Behat. Answers to these questions would shine a light on Sylius test strategy :)

Thanks.

Documentation Help Wanted Stale

Most helpful comment

@pamil Awesome! Thanks Kamil for quick and detailed response. You Rock dude \m/

All 8 comments

Hello Aram! :)

  1. The main difference here is that scenarios in these suites are rewritten to be universal both for UI and domain testing in contexts. /cc @pjedrzejewski
  2. I introduced javascript suite first with javascript testing, because there were some issues with base_url setting being the same in symfony2 & selenium2 drivers. The driver is determined by MinkExtension configuration options - default_session and javascript_session, and the scenarios using JS have @javascript tag, just like before.
  3. Currently I'm refactoring PageObjectExtension (as an extension for that extension :)) to be more defensive - e.g. not extending DocumentElement in Pages will ensure us that all the logic related to UI stays in pages. I'm almost sure that using it will make our Behat contexts a lot cleaner.
  4. Cached profile is using the environment which should behave just like a production environment, but has a different database. There are also ORM / ODM metadata caches enabled, which aren't the default production setting, but are strongly encouraged. In order to run test in cached profile, test_cached environment, you need to do the cache warmup first.
  5. Contexts and pages are rather coupled with Sylius Core (except for DoctrineORMContext, purging the database before scenarios). There are also two (or three after my refactoring from 3.) Behat extensions, that are generic and can be used standalone:

    • SymfonyExtension - isolates the driver kernel, so contexts and "web" are not sharing services anymore, it makes our suites more fail-safe and driver independent.

    • PageObjectExtension - cleaning the original extension, described in 3.

    • SymfonyPageObjectExtension - needs both previous extensions, contains PageObject logic specific for Symfony (e.g. generating and matching URL from route)

If you have any further questions, feel free to ask, I'll be pleased to explain the changes :)

:+1:

Wow, awesome @pamil, great explanations. We have an AngularJS-based admin so a lot of practices that you've described can help us in our tests.

We were using Protractor (Angular-recommended testing tool) but after a few months we've faced with a lot of issues now I'm trying to see if we can use Behat instead. So far it is going very well actually.

@pamil Another question :) I was looking through the new Behat contexts and scenarios. I saw a lot of transformers being defined but I couldn't actually find a context which is making use of them.

For example I expected to see $product here on this line because there is a transformer here but instead there is $productName and a call to product repository!

Why transformer is not used here? A mistake or a point I'm missing here?

@aramalipoor the rule of thumb is to use transformer if we want to get existing entity by some property and not to use it if we are just creating the entity. Transformers can only transform matched content, so given there is step I do something with product "Foo bar", there are two behaviours:

  • @When /^I do something with product "([^"]+)"$/ - only the string inside quotation marks is matched, I do something with product "Foo bar"
  • @When /^I do something with (product "[^"]+")$/ - the whole expression is matched, I do something with product "Foo bar"

That matched argument string is passed further to the transformers. so product "Foo bar" is a matched by /^product "([^"]+)"$/ and transformed to a Product instance, but Foo bar is not :)

The use of transformers can be spotted almost everywhere, eg. in Ui\ProductContext or in Setup\ShippingContext, just make sure they are the new ones (Sylius\Behat\Context\*).

You may also want to have a look at the Sylius' Behat guide which has a section for using transformers written by @Zales0123 :)

@pamil Awesome! Thanks Kamil for quick and detailed response. You Rock dude \m/

@pamil I used SyliusResourceBundles and some other Sylius bundles in our app. how can I use and integrate with your BDD test infrastructure?

Currently I'm copying your classes into my own Namespace\Behat namespace due to some hard coupling and final classes! Idk if this is the right way to bring BDD into our application?

Thanks :)

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in a week if no further activity occurs. Thank you for your contributions.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

stefandoorn picture stefandoorn  路  3Comments

ping86 picture ping86  路  3Comments

crbelaus picture crbelaus  路  3Comments

loic425 picture loic425  路  3Comments

mezoni picture mezoni  路  3Comments