Technical
July 13, 2022

Getting To Know Your Code - Building Test Suites

Getting your first software engineering job is incredibly exciting, but can also be daunting. As you ramp up in your new role, take the initiative to include time to create testing suites for the software. A fantastic addition to your onboarding so you can begin to understand the code you will be working with.

You did it! You landed your first software engineering job! You show up on your first day, you get access to the code repo, you clone it onto your computer, you open it up and… good lord… that’s a lot of code. It’s far larger than any of the projects you’ve made for your portfolio. It utilizes libraries you’ve never heard of, complex authentication patterns, and more endpoints than you can keep track of.

How would you even begin to understand the code base? That’s where unit testing comes in. 

Ideally, companies have effective methods of ramping up their new software engineering hires, but unfortunately, this isn’t always the case. This is why it’s important to take learning the code into your own hands - so you can onboard yourself.

One of the early assignments I received in my first professional role as a software engineer was building unit tests for our software’s API endpoints using Jest. This work proved invaluable in creating a foundation of understanding about how our code runs to make our software work. I learned 

  • The structure of the objects we created
  • How objects are connected to each other
  • And exactly what each endpoint returns

For instance, I learned that our Paths By Customer endpoint would return all paths associated with a customer. With that knowledge I know whenever I need to return paths associated with a certain customer, I don’t need to make a call for all paths and then filter them by the customer ID. I can just call the Paths By Customer endpoint and it will fetch the specific paths I need. 

Creating tests also gives you structure for learning code. You can increment the code into smaller aspects of exactly what you want to test and master before moving on to another. My first test suite only focused on paths. I created tests that assessed creating, updating, and deleting paths, ensuring they contained all necessary properties, and if they were associated with the correct customers and learners. Once I was finished with paths, I felt comfortable moving onto testing assets. I followed this pattern until I had created testing suites for all of our API’s endpoints and objects. Having a clear direction and structure reassured me that I was learning the entire code base in a logical manner, while also learning the coding and testing conventions of the team. 

Getting your first software engineering job is incredibly exciting, but can also be daunting. As you ramp up in your new role, take the initiative to include time to create testing suites for the software. A fantastic addition to your onboarding so you can begin to understand the code you will be working with.

By
for Edify

You did it! You landed your first software engineering job! You show up on your first day, you get access to the code repo, you clone it onto your computer, you open it up and… good lord… that’s a lot of code. It’s far larger than any of the projects you’ve made for your portfolio. It utilizes libraries you’ve never heard of, complex authentication patterns, and more endpoints than you can keep track of.

How would you even begin to understand the code base? That’s where unit testing comes in. 

Ideally, companies have effective methods of ramping up their new software engineering hires, but unfortunately, this isn’t always the case. This is why it’s important to take learning the code into your own hands - so you can onboard yourself.

One of the early assignments I received in my first professional role as a software engineer was building unit tests for our software’s API endpoints using Jest. This work proved invaluable in creating a foundation of understanding about how our code runs to make our software work. I learned 

  • The structure of the objects we created
  • How objects are connected to each other
  • And exactly what each endpoint returns

For instance, I learned that our Paths By Customer endpoint would return all paths associated with a customer. With that knowledge I know whenever I need to return paths associated with a certain customer, I don’t need to make a call for all paths and then filter them by the customer ID. I can just call the Paths By Customer endpoint and it will fetch the specific paths I need. 

Creating tests also gives you structure for learning code. You can increment the code into smaller aspects of exactly what you want to test and master before moving on to another. My first test suite only focused on paths. I created tests that assessed creating, updating, and deleting paths, ensuring they contained all necessary properties, and if they were associated with the correct customers and learners. Once I was finished with paths, I felt comfortable moving onto testing assets. I followed this pattern until I had created testing suites for all of our API’s endpoints and objects. Having a clear direction and structure reassured me that I was learning the entire code base in a logical manner, while also learning the coding and testing conventions of the team. 

Getting your first software engineering job is incredibly exciting, but can also be daunting. As you ramp up in your new role, take the initiative to include time to create testing suites for the software. A fantastic addition to your onboarding so you can begin to understand the code you will be working with.

Like this post? Share it!