Status Open Bounty end-to-end automation about swarms HOT 13 CLOSED

@oskarth I am going to update the idea after getting approximate dates for creating SOB deployment in Jenkins and defining who is going to add more end-to-end tests

from swarms.

@antdanchenko What's the state of this swarm? Is the MVP done (deadline 28th November) or is it postponed?

from swarms.

@oskarth it's almost done, except CI. There is no SoB build in Jenkins, yet

• Infrastructure for test runs - Done

• A test for adding bounty to an issue is created - Done

• Jenkins automation job is running after each successful SOB build - Pending

from swarms.

@antdanchenko nice! what is the new goal date for MVP? are you planning future iterations after this or is this it?

from swarms.

@antdanchenko What's the state of this?

from swarms.

@pablodip sorry for late response, but better late than never

@churik is going to proceed with this idea, an update on second MVP will be added soon

First MVP:

• Infrastructure for test runs - Done

• A test for adding bounty to an issue is created- the test is added

• Jenkins automation job is running after each successful SOB build - Jenkins job is running by manual trigger, SOB product build isn't in Jenkins

from swarms.

MVP v2 is added

from swarms.

@antdanchenko No worries, sure better late than never! :)

Some questions about this idea:

• Why are these tests being written in Python? Wouldn't it be possible to write them in Clojure? It would have great advantages by accessing the core of the system in the same language. It would also require less global knowledge to maintain the whole SOB.
• Could some documentation be added to the README of the SOB about how to run these tests in local?

Thanks! :)

from swarms.

@pablodip

• Python has been selected as primary language for automation in order to involve whole QA team in creation/maintenance of automated tests.
  Test creation/maintenance in Python requires much lower skills than doing the same in Clojure.
  The idea of e2e tests is to execute the same steps as user does, instead of accessing the core of the system (I might be wrong in this definition)

• Documentation will be added

from swarms.

@antdanchenko Thanks for replying. :)

It makes sense to use Python if it is going to be maintained by people with no enough knowledge of Clojure. Another possible solution could be to use an indirection layer as Gherkin, so that no Clojure knowledge would be needed even if describing tests on top of it.

Regarding the usefulness of accessing the core language of the system, I can think of two benefits right now:

• Even if tests are from outside the system, the system has some state, and being able to initialise it and access it with all superpowers of the core language might be very useful.
• Tests use data, even if they are from outside the system, and being able to generate and validate that data would help a lot I think as well. This could be available once the SOB uses spec.

Just some ideas for possible future iterations of this swarm idea, not to interrupt the current one. :)

from swarms.

@arash009 please review MVP V2 - I changed it according to fact that we probably have a different workflow in the nearest future, so I included only GH functions, which are obviously essential for building tests.

from swarms.

Perfect! I dont think the GH PR/Merge process will change, or not very much, so that should be fine.

from swarms.

Closing this issue as part of spring cleaning. If this idea is still relevant, please submit a PR per https://github.com/status-im/ideas/#contributing. If you feel closing this issue is a mistake, feel free to re-open.

from swarms.