Our team project has been steadily improving over the course of the semester. My team has been absolutely awesome because we are all willing to meet on the weekends and work together to accomplish milestones in the project. We did not know each other at the beginning of the semester, but we have quickly become very trusting of each other's skills and play to our individual strengths and weaknesses very well. Together we have learned how to navigate the command line, merge our ideas with GitHub, write automating BASH scripts, build HTML pages, compile and run drivers, and program in C++.
Our first milestone came when we met up together to clone, compile, and run our original project choice: the mWater app. Due to lack of helpful documentation and a ridiculously complicated list of dependencies, we decided (with some advice from Dr. Bowring) to not continue with testing mWater, but to work with Celestia, a space simulation application that has been around since the early 2000s. Even though it was unnecessary, Team International (that's us!) got together one Saturday morning and composed a lengthy documentation of every step it takes to get Celestia running on an Ubuntu LinuxOS using the terminal.
After successfully being able to use the open source program, our next challenge was to begin writing tests to analyze the reliability of the software. We chose to run our tests mostly on the Math Library because some of the simpler methods (such as squaring a number or finding the area of a circle) were easy algebraic or geometric calculations that we could perform ourselves. Working with a C++ library proved challenging because we could not run the code from the command line - we had to create a .CPP driver first which we would have to compile before we were able to pass any inputs to the mini-program. Our team worked late into the night to get the drivers working and by now, it seems like it should have been easy!
We have just finished working on automating the testing process using a BASH script that will iterate through all the testCase.txt files that we will make (at least 25 of them), use the associated driver to pass an input to, and compare the return value with the expected value. And, once this magic is complete, we will open an .HTML file that displays the results of the test in a browser window. Again, after many texts, meetings, late-night delivered pizzas, and excited "whoops" of triumph later, we are almost to the point where we just need to clean up our project and make it presentable. If we are to make our GitHub repository public, we will need to organize the project a little bit better and provide better documentation of all our steps.
We have all felt that the project has greatly increased our knowledge in a variety of directions. I myself had never even written a script before this course, so I consider it a huge success that I can now write one that uses the information in my file system as fodder for its calculations. Good job, team!
