Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Dono Greeff
    @Greeff
    Regarding the API based vs UI based... It is good practice to keep the user journey tests away from GUI test automation as they should be separate scopes. Also generically UI automation only tests on code assertions, not whether the UI looks good from a UX perspective.
    Simon Paitrault
    @Freyskeyd
    Ok, in fact I need to make test like this one:
    • Connect one user to a particular page (on the app), press one button or two. add a text in a box
    • Connect another user and interact with the first one and validate that both can communicate and everything is ok.
    And I also want my PO/PM to write acceptance tests which will run automaticly. Also regression tests (visual/etc)
    Dono Greeff
    @Greeff
    Cucumber is generally used from a (singular) users view. However if written creatively can still work fine considering 2 users. I personally have broken that better practice to good effect. It really comes down to what works best for you.
    Regarding the PO/PM writing the acceptance tests, Just make sure they understand having D R Y gherkin.
    Who will code the automated part of this test suite? You will need to consider that too.
    Simon Paitrault
    @Freyskeyd
    PM already know how to write gherkin, developers will do the code in background
    Dono Greeff
    @Greeff
    Knowing how to write gherkin and keeping it D.R.Y are two different things ;) It will also help to lesson the load onto the developers as they wont have to duplicate work on existing steps etc.
    Simon Paitrault
    @Freyskeyd
    yep
    I'm really confused about what I must do
    I want to test the end user application to replicate common usage before and after deployment. I don't want to touch the architecture (system, DB)
    I was thinking of writting gherkin tests (representing what we manualy do for now)
    but I want something helpful and easy to understand
    Dono Greeff
    @Greeff
    As in a guide to follow in how to start from scratch?
    Simon Paitrault
    @Freyskeyd
    yes
    start small to validate and then improve to something that really work and make my product stronger and my team more confident on deplyoment
    Dono Greeff
    @Greeff
    Yes that is a good approach to take.
    You will need to decide in what language your framework will be coded. I suggest getting the developers input here, That will naturally lead you to the appropriate cucumber flavour you need.
    Simon Paitrault
    @Freyskeyd
    it's better to take cucumber instead of behat?
    Dono Greeff
    @Greeff
    From what you were saying, you want documentation that also serves the purpose of acceptance testing...
    That is cucumber's solution as per the text book.
    Behat, I have never tried. But if that is what suites your application then go for it.
    Simon Paitrault
    @Freyskeyd
    My team did more php than ruby
    Dono Greeff
    @Greeff
    I just read up on it. Behat is the PHP implementation of Cucumber
    Simon Paitrault
    @Freyskeyd
    but we are on scala now
    You can use scala with cucumber too
    The important thing to realise here is that cucumber is a documentation layer. The code that runs the tests is your framework layer. Keep those independent.
    It will mean less pain later
    Simon Paitrault
    @Freyskeyd
    ok
    Simon Paitrault
    @Freyskeyd
    Is it better to use selenium or something else?
    Dono Greeff
    @Greeff
    Personally I do not like selenium, it highlights the point though... It depends on you. What do you prefer/like. What gets the job done in the best time/effort
    Sorry for the vague answer, but it shouldn't be someone else's call as we do not know all the intricate details of how your project functions. You do, therefore, you are best qualified to make that call :)
    Björn Rasmusson
    @brasmusson
    You should should use the same programming language in your step definition/framework layer as your application does, and choose the flavor of Cucumber based on that:
    Ruby -> Cucumber-Ruby
    Javascript -> Cucumber-JS
    Languages on the JVM -> Cucumber-JVM
    C# -> Specflow
    PHP -> Behat
    Python -> Behave
    Dono Greeff
    @Greeff
    I dont fully agree with that. Even more so in a micro service architecture. With microservices one of the benefits is to use the language appropriate for that service. So you could have a complete mix of languages. Given this is a user workflow automation suite it should be considered as its own project/service and by that should also be free to dictate whatever tools/languages it needs to get the job done.
    Marit van Dijk
    @mlvandijk
    Thnx @Greeff for clarifying my point ;)
    Dono Greeff
    @Greeff
    No worries. Good to meet like-minded folk :)
    Marit van Dijk
    @mlvandijk
    @Freyskeyd if you're testing the UI, I'd assume you're also testing that it looks nice, can click buttons etc. If you're testing the process (i.e. as user can log in, order a product, get a confirmation - you don't have to do that through the UI). But starting at the UI is what most people do when they come from manual testing, it's the natural starting point. It's fine; just be aware there are other options
    Simon Paitrault
    @Freyskeyd
    @mlvandijk Yep I will do it steps by steps :P
    Marit van Dijk
    @mlvandijk
    If you're going to talk to browsers, you'll very likely end up using Selenium. As that's exactly what it's meant for. Other tools that talk to browsers, likely wrap (incorporate Selenium anyway)
    Unless you're using Cypress.io which talks to the browser differently
    But it's javascript and I don't javascript that well...
    @Freyskeyd Your example scenario might not be the best to automate through the UI though. I might start with some simpler ones
    Also, I know many people don't like Selenium, not sure of better alternatives (apart from possibly Cypress.io). In my experience this also has a lot to do with unstable xpaths etc. So my main tip there would be to get the developers to add unique labels to the UI elements you need for your tests (or better yet, do it yourself if you can ;) to you can operate on those, even if the screen layout changes. We do that and our tests through the UI are relatively stable...
    Ofcourse, if the application is developed by a different company, you can't do it that way
    Marit van Dijk
    @mlvandijk
    @Greeff likewise :)
    lwouis
    @lwouis
    Hi guys! I'm looking for a way to enforce a maximum line-length on my .feature files. I found some gherkin linters, but they seem broken/abandoned. What do you guys use to format or lint your .feature files? :)
    Oh I should add that my project is an angular app, so it would be a bit heavy to use a library not on npm (a ruby gem for example)
    Eric Kessler
    @enkessler

    @lwouis
    A few gherkin linters that I have used.
    https://github.com/funkwerk/gherkin_lint (idle)
    https://github.com/r-cochran/cuke_sniffer (abandoned)

    And a tool that I use when the 'out of the box' linters don't cover my needs and I need to write custom lints/queries.
    https://github.com/enkessler/cql