Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Marit van Dijk
    @mlvandijk
    That's at least what my team tries to do. Even though we do have a few tests running through the UI on the test environment. That's mainly a smoke test, since we also rely on services made by other teams (and I'd like to at least see it work on an actual environment before deploying to production). Most if not all of "our" business logic is tested before then (& by stubbing external dependencies)
    One thing I've noticed happen is that existing manual regression tests are automated as it. While with automation you can do so much more...
    Simon Paitrault
    @Freyskeyd
    hello @mlvandijk The UI tests are run to validate UX and UI. Also CSS regression.
    Dono Greeff
    @Greeff
    Hello, I agree with Marit here that you would want your BDD tests to test the business flows, so keeping it API based. @Freyskeyd For the UI/UX testing have you considered something like MABL?
    Simon Paitrault
    @Freyskeyd
    @Greeff I can't test API directly because a lot of features are dependent of the presence of the UI
    What do you mean by API based (maybe I don't understand)
    Simon Paitrault
    @Freyskeyd
    @Greeff MABL looks good but I don't have a lot of budget for that. I need to prove the viability of such tests first.
    Dono Greeff
    @Greeff
    Apologies, I made the assumption that your UI's would have been built on the API's given the microservice architecture. UI tests using a BDD tool like cucumber is often expensive as it takes a long time to execute. Also if the UI is changing quite often there is the re-work cost for every change in you automation. These costs can be put together to build a business case for using a tool that handles UI automation in a better fashion. Currently I believe MABL is free for public BETA. No harm in trying it out and then offering it as a showcase for consideration.
    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