Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Michael Gerdemann
    @gerdemann
    @stof or @everzet? :-)
    PurHur
    @PurHur
    Its very quiet around the old behat maintainers. The best thing you can do is to advertise for more development, get the maintainership and do it on your own.
    Michael Gerdemann
    @gerdemann
    Yeah, I know... In this case, not even anything needs to be programmed. It takes only 3 clicks on Github to create a new release.
    PurHur
    @PurHur
    Yes its really sad. We have to buildup the community again. Probably its a good idea to spam here if the old maintainer is still online
    but this community isnt really active at all
    Michael Gerdemann
    @gerdemann
    I just thought I would write it here again, hoping that the old maintainers would read it somewhere
    Jeff Martin
    @RunCrywolf
    Hey guys, I know pantheon released an article on using Behat for unit testing on js environnement, would you say it can also be used for suiteCommerce which is also made in JS? Let me know, there could be a lot of potential! Thanks 🙏
    pcfreak
    @pcfreak
    Hi
    I keep getting an error that my " context class not found and can not be used."
    its not autoloading probably even though it's in the bootstrap directory
    I'm declaring the path in the .yml file as well
    pcfreak
    @pcfreak
    ok I'm past that stage
    Even André Fiskvik
    @grEvenX
    Hi all! Anyone managed a service with many automated behat feature definitions? Currently we have approached it with one FeatureContext and a bunch of traits, but the whole thing becomes unmanageable and hard to reason about. I wondered if there was anyone with previous experiences in this case or if there were some good examples for bigger open source repositories that has a good way of structuring it.
    PurHur
    @PurHur
    If you come back grEvenX" You can use as many FeatureContext Classes as you like. Probably that is what you have done with the traits
    just list them in the behat.yml
    Even André Fiskvik
    @grEvenX
    yes, I'm aware you can have several. But I'm still struggling with how to organize it in a way that makes sense. Would have been nice to see some good examples
    PurHur
    @PurHur
    I cant show you my test repos but there are "generic" FeatureContexts and then a ApplicationFeatureContext and mostly a MailContext
    how many do you have?
    Even André Fiskvik
    @grEvenX
    I currently have a huge FeatureContext split into "feature" by trait. Now I'm trying to see if it should be a FeatureContext "per feature group" instead
    PurHur
    @PurHur
    I dont try not to write to many specific sentences and stick to the basic concepts of mink or json testing and write the tests not very "customized". I dont have a sentence for each test.
    That is more on the behaviour side of the user. Since else you could skip an important step of the behaviour driven testing if everything is written in code.
    Even André Fiskvik
    @grEvenX
    So you write more low-level scenarios compared to high-level scenarios?
    more closely to the UI itself, rather than the overall business requirements
    PurHur
    @PurHur
    yes
    Else i would use codeception sinde its more on the cody side
    Or just phpunit if you want to test business logic. The adventage of behaviour testing is that you follow the path of a user.
    Even André Fiskvik
    @grEvenX
    I guess it depends what your view of "behaviour" is, this is a mine-field with different practices spread across different developers :P From some of the inventors behind gherkin/cucumber, my impression is that they recommend using it more for high-level behaviour than low-level, as it becomes brittle and closely related to an "UI". In my case, I don't even have a UI, since it's all a REST API.
    currently use phpunit for simple unit tests
    PurHur
    @PurHur
    APIs are the same. you still expect some values in the endresult to "read". But i see your point. Behat is used in very different ways.
    Even André Fiskvik
    @grEvenX
    but I'll take a look at codeception, looked interesting
    PurHur
    @PurHur
    i saw behat tests where the whole thing to test got mocked away behind "magic"-backgrounds and some magic conditions in the sentence
    in the end it doesnt test more that "is it callable".
    PurHur
    @PurHur
    than low-level, as it becomes brittle and closely related to an "UI"
    and for that: I really want that! Thats is what showing me if the software is working. Imagine a Feature which a Background a User cant fullfill because the UI doesnt allow it.
    But still there are sentences like "if the user opens the profil menu" (could be if the frontent want the profile menu as json) i wanne see....
    Even André Fiskvik
    @grEvenX
    How do you deal with Fixtures, backgrounds and "givens" for your scenarios in that case? I guess you don't go through these "UI" layers to configure existing state?
    PurHur
    @PurHur
    :D
    you got it
    a lot of pre tests in the right order
    Even André Fiskvik
    @grEvenX
    ugh :P
    PurHur
    @PurHur
    background and givins are no problem but fixtures... yes its more that the stack doesnt allow fancy shit and is always started with a dump so its there
    but if i wanna test the booking feature yoy have to run the registration features for a new user before that because all the following things depend on a new registeres user
    That is no problem because it is already written. And i dont even want to know if the booking doesnt work for a new user when a user cant even register
    pmaasz
    @pmaasz
    What you could do is test the routine of register a new user in behat and then write a php version of this routine into your FeatureContext using it as an Annotation call like „@registerNewUser“. I haven‘t done that one specifically but i wrote something like that to login users. For example „@loginAdmin“ or „@loginTestuser“. All My tests require no data at the beginning. That way it gets easier to use in pipelines but the runtime is a down side. I have thought about a sql dump service to provide mock data but I scrapped that idea. I still have the Problem of an exploding FeatureContext sizewise. The behat project could provide a solution by providing more features and sentences in the framework but it seems the maintainers have vanished.
    PurHur
    @PurHur
    Hello pmaasz
    This would only move the lines from my feature files into a php file. I want my testers to write that.
    pmaasz
    @pmaasz
    If
    pmaasz
    @pmaasz
    If you have the testers that would be the best option.
    PurHur
    @PurHur
    You dont need dedicated persons to write that. Its only like 2 lines or something like that. It doesnt cost that much.
    pmaasz
    @pmaasz
    I tried Scenario Outlines for the first time for the registration steps and it makes the tests pretty compact. It's even less work to write but the test runtime is the same.