I tried out KodeKloud Engineer this morning, and I was favorably impressed. This is a good tool for practicing real world skills. And I, like many others it seems, stumbled at the first challenge of making a script executable.
The challenge seemed simple enough, and I, like many others, fulfilled the task to the letter; But I failed. Why? Because the script wasn’t “executable to all users”. That was the key instruction. How to make it executable to all users? I wasn’t sure, so I had to try several solutions and test them by trying to execute as the logged in user.
This got me thinking, the evidence that I had succeeded at the task was the simple test of trying to execute the script. But this highlights that what is needed to ensure that pretty much any DevOps work is done is a test. Usually this testing is ad-hoc, answering the question: “Does it look right?” or “Does it solve this one narrow use-case that I have in mind now?”. This skill of “test-driven-DevOps” doesn’t seem to be acknowledged or taught commonly. Going back to the example of execution of a script, if I were to make a more elaborate test, I might do something like this (in pseudocode):
For all the users on the system, attempt to execute the script.
You could easily make a test like this in Python; Simply read out the users from configuration files on the system, and attempt to execute the script in a sandboxed shell as each user.
So seemingly, finishing this task or any task, would benefit from submitting a test that my supervisor (or any other person) might use to verify my work. This also has the advantage of documenting what was done, and what was expected; Similar to how development tests are documentation.
This might be an interesting method of training going forward: Not only completing what appears to be a task with some piece of software, but also generating a test that can be used to verify the task is complete; and provide evidence for the same.