Alright, it’s official. We’re clear to start working on the project. I’m not sure if you want to list our team (3 of us) as maintainers, but the odds of us not pushing this project to completion is quite slim. At this point we’d have to redo quite a bit of work if we wanted to do something else. So yeah, we’re moving.
Our current timeline is to push out a hello world super soon, which is where we will need to make sure that we have a way of storing our code that can eventually be merged in when completed. I’m assuming a github repo, correct? That seems to be what our professor desires. This is also our software setup as far as the different working pieces. We could touch base to just make sure it’s all packaged properly, and save us time later.
Then we’ll build a prototype, that contains basic functionality. That should be done by the end of the month, with time to spare for us to get back to you and ensure it’s what you’re looking for.
From there, our plan is to expand outwards, installing additional features (as far as command-line options, quality of life improvements, better support, etc), and eventually, hopefully, moving on to create the outside-vm module afterwards. It’d be nice to have the inside-vm component done by the end of the month in it’s entirety, and after that moving onwards to bigger and better features. One executable that allows the creation of multiple VM’s, and tests that run on those VM’s, would be wonderful. This would involve the outside-inside VM communication as previously discussed, probably over the virtual network using TCP/IP. This would come after the completion of the inside-vm component as a standalone.
From our design meeting: libvirt, and other features that start and stop VM’s would need to run on the host, so those features would actually be part of the outside-vm component, to be built later.
As for the inside-vm component, which is our first priority, software decisions currently are:
behave will be our cucumber-like component. It is python-based and semi-official. It will allow us to keep things in python, with a bash script to get it all going. We’ll eventually create some of your previously suggested test-cases when it comes time to create the prototype.
Dogtail is a possibility for our GUI tool, we’re unsure as to whether or not it’s sufficient, but it has python 3 support so. We’re looking into running that as our working GUI automation tool. Realistically, Dogtail seems to have slow development but it looks mature.
As for any legal stuff, just credit for our work is sufficient. We’ll probably link to the code repo from our github accounts. A resume addition, essentially. Do what you will with it, sell it, whatever.
We’ve also recognized that part of this project involves creating effective documentation as to how to create test-cases and make use of the tool. This should be something that anyone could read, and make sense of. This work is factored in to our plans. It should be easy for other contributors to add test-cases, and we see creating a proper set of test-cases as somewhat outside the scope of our project. We’re just looking to create the test-cases set you suggested, and generally ensure the software is working properly and has all required features. The suite of test cases, and the possible features for the test-case definitions will need to be expanded over time.
As long as it’s sufficient for us to use our own repo, to hopefully be merged when the work is completed, we’ll use the repo previously linked on this post - the one for the project proposal. Our documentation to accompany the software can go on the wiki for that repo.
Thanks for the help, contributions incoming.