<div dir="ltr">Hi all,<br><br>as hopefully everyone knows, it's very challenging to prove that Bash encourages<br>writing readable, maintainable code that actually works first time it is run.<br>Sadly we have quite a long history of merging various shell scripts without any<br>test coverage.<br><br>Fortunately Peter Zhurba bore with me and we decided to use bats[1] to test his<br>fuel-migrate[2] script. Obviously it's close to impossible to properly code that<br>uses ssh or rsync, but it's good enough for functions that take some arbitrary<br>data and return another set.<br><br>As we have quite a long history of merging various bash scripts without any test<br>coverage, I'd like to introduce more formal rule requiring engineers to ship any<br>bash code longer than 100 lines with unit tests. BATS tests are not currently run<br>by our CI, but we're getting there[3].<br><br>My TL;DR skills are nowhere close to Dmitry Borodaenko's but let me try: bash is<br>terrible so let's do our best to make it work as we want it to.<br><br>What is your opinion?<br><br>Bartłomiej Piotrowski<br><br>[1] <a href="https://github.com/sstephenson/bats">https://github.com/sstephenson/bats</a><br>[2] <a href="https://review.openstack.org/#/c/198355/2">https://review.openstack.org/#/c/198355/2</a><br>[3] <a href="https://review.fuel-infra.org/#/c/9130/">https://review.fuel-infra.org/#/c/9130/</a><br></div>