Background
During my time at Lambda School I have built Machine Learning models, built APIs, created databases, and written articles. I was still in for a surprise for my first experience involving a pre-existing codebase and external stakeholders.
Story Squad; It is an app built with the goal of engaging young children in the imaginative and creative world of fictional literature… with a twist. Rather than reading a book by themselves, Story Squad gives children a smaller portion of a story to read, then prompts them to expand on the story and illustrate a perspective from the story. Each child is paired with a teammate of similar reading comprehension, and matches up weekly against another team of readers, all reading the same story snippet you are. The goal is to have more points allocated toward your team’s individual story expansions and drawings than the other team. This happens through a clever point system where each player has a set amount of points to cast for each other’s work. It retains all of the beneficial brain activity associated with reading, and does it in a modern way that engages children using familiar gameplay concepts.
The project
This was my very first experience working with a pre-existing codebase. My team was tasked with building a test suite for the existing API endpoints that either rendered visualizations for score comparison, or involved the submission of the student’s creative text / illustration.
From the start, this was different from anything else I had worked on to date; There was already so much code in place to get familiar with as opposed to building something from the ground up with complete creative control. I was also working alongside more developers than I ever had. The task itself was straightforward enough, but the real challenges presented themselves in the shape of environment setup, understanding someone else’s code to a proficient enough level to build a functioning test suite, and staying organized with a team.
The first part of this whole process was to get to know my teammates, and agree with them on how we were going to divide the work. Initially we had different priorities, different ideas, and different communication styles. The importance of a well focused team cannot be understated, and everyone seemed to at least agree on this. Product roadmaps, clear goals, and prioritization are always important on a project. With a team though, the importance of these is magnified, as we have to align our individual ideals. After a couple days of getting to know each other, we were all on the same page and ready to code. At least I thought.
It turns out the product had been built from a Linux perspective. To those that don’t understand what this means, Linux is a different operating system entirely than Windows; a program built using one of these operating systems could present difficulties when using the other to iterate on the product.
I am a Windows user…
Immediately I was having issues running commands. I could not figure this out myself, but luckily some of my savvy teammates were able to push me to the right resources. The fix was to install WSL, “Windows Subsystem for Linux”, on my computer. As the name might suggest, WSL allows Windows users to run a “Subsystem” on their machine that uses Linux. First obstacle? Overcome. I was now running and ready to dive in.
“If I have to build tests, I have to understand what I am testing.”
I didn’t build any of these functions. I didn’t name any of these variables. How do I know what to test? This was someone else’s story that I had to read to understand. This was incredibly daunting to me.
As I understood some, I was able to begin writing simple tests. As I understood more, I was able to write more complex tests. As it started to feel as if I had written the code, I was able to see where it could be improved upon for even better testing! Even simple input tests had room for improvement.
One particular part of my endpoint was a Pydantic Model class; an object that is used to ensure uniformity of data types. This made testing inputs tricky, as the Pydantic Model corrects some discrepancies by itself. For example; I wrote a test to ensure a function fails if an incorrect data type is used. It did not initially work as the Pydantic Model will change the data type and the function will work; not good for testing. My fix was to add error statements to the function itself so that I could test for specific error statements.
If in the future the app is modified to not use Pydantic Model classes, my tests and error messages will notify the developers that the inputs are breaking the function.
In reflection
Once the ball got rolling, it was very fun. It was like learning the rules to a game you don’t know and the excitement of getting better. I was now thinking in someone else’s code. By the end of this experience I had gone head first into a robust codebase, built a well functioning test suite for my endpoint, and learned how to communicate with people of different skills and backgrounds to align our goals and effort.
In hindsight, this was the most difficult development experience I have had to date. It was the first true asynchronous test of my tech and soft skills. There was so much going on. In reflection is when it is easy to see what I might have done differently and where I would like to see things go.
I should have sometimes leaned on my team more for help, as I could have been more productive with my time. I should have also pushed myself harder in certain areas and not leaned on my team so much. I should have taken the planning process much more seriously, as the importance is magnified when working with people other than myself.
Overall, I am happy though. We left a great base for the next team to expand on and had a fun time doing it. We went through the gauntlet together. The next team will be able to begin testing response codes immediately and have the direction to apply some of our processes to other endpoints. I would like to see the next team take what we created to the next level in terms of API testing, and I want to see how the work grows as others add on to it. Only as a team can something so unique be created.