Write tests, rubymasters please help!

[EugenMayer]

Its not like i do not write tests, but this here is pretty special. Containers, remote file sync and so on.

Any rubyist available to explain, how this would be done in a considerable amount of time?

Anyone who feels happy to structure the test-idea for this project, please go on!

[BKStephens]

Because the Ruby code is for scripting and makes calls to executables outside of Ruby, unit testing probably wouldn't work.

TravisCI is free for open source, and you can use OSX. We might be able to use TravisCI to run some high level tests for us.

[ignatiusreza]

testing the full syncing process them self is going to be quite complicated, but, we can at least have some test for initialization parts, like loading + parsing configuration and checking dependencies.. we should be able to have an empty OSX box and have precondition code runs on it and test that the proper dependencies gets installed..

in related to #265 , since I'm going to refactor quite a bit of the configuration part.. I would like to start writing some test for it.. do you have any preference on which test runner should be used, e.g. minitest or rspec?

[EugenMayer]

Great! Rspec is at least the one i am used to in ruby.

Looking forward to see you starting this, i am sure i will join you on that!

[michaelbaudino]

Just sharing some thoughts here: RSpec::Bash may be a good tool to write some basic regression tests, like:

0. have a test filetree and a test docker-sync.yml file
1. start bin/docker-sync start
2. add/delete/modify a file in filetree
3. check that modifications have been properly applied inside the *-sync container filetree

We could aim to have a complete set of docker-sync.yml files for multiple cases (for each OS, each sync strategy and each watch strategy, at least, I'd say... and maybe even for each config option).

And as @BKStephens mentioned, we could then totally configure a full CI/CD workflow using Travis ✨

Has anyone some experience with RSpec::Bash? Or any other shell-based testing framework? I'd be happy to help if I have time 👍

[EugenMayer]

Any help here is diamond, since we fight with regression bugs a lot!

I do not think we can use travis since it would not support starting docker-container?

[ignatiusreza]

Rspec::Bash looks promising.. 👍

In term of CI, circleci v2 support docker, though I need to double check if they support this only through configuration, or if we can actually spawn new containers on the run..

[michaelbaudino]

@ignatiusreza I just saw that we can do pretty much what we do with Docker and Docker Compose on Travis: https://docs.travis-ci.com/user/docker/

Also, Travis' matrix allows us to run the test suite with multiple Ruby versions (and maybe even multiple Docker versions or multiple OSs), which sounds like exactly what we need.

[EugenMayer]

that is new with travis + docker..wow

[EugenMayer]

we could use https://www.inspec.io/docs/reference/cli/ to test the container state

inspec exec test.rb -t docker://container_id

i am using inspec with kitchen/chef a lot an i love it, i was not aware they had a docker driver.

[jacob-s-son]

Just a thought, WDYT if the effort is pushed towards into building good End-To-End tests (checking that the tool is doing what it's supposed to) and be open to reimplementing this in some other language at some point? Don't get me wrong - I am Ruby developer myself, but there are advantages this tool being distributed as a single binary instead of requiring Ruby and gem installation. Crystal might be a good candidate.

[EugenMayer]

@jacob-s-son i am open e.g. for an implementation in GoLang or similar, but i learned its more then people talk about that, then actually doing anything.

I am not religious toward ruby at all, to be clear, i do not like ruby ( at all ). But it`s the tool offered good tooling with thor to the given type, fitted my knowledge in devops and thats it. There is no other reasons to ruby being selected then "timing"

[jacob-s-son]

@EugenMayer , I came by issue tracker as we are close setting up our application with docker and starting to convince team to adopt the new workflow. I will ping you, when our team members start using this toolchain, until then asking my employer to devote some time to something we don't really use yet will be too difficult.