harisrid Tech News

A primer

Hi all,

I briefly want to talk about a strategy ¹for onboarding junior engineers; writing out unit tests and engaging in code refactors.

Usually, I’ll write up JIRA-esque user stories and tasks instructing something along the following :

The JIRA-esque testing user story

Subject line : [Testing] <Insert_Feature_Name> Bolster unit test coverage metric to exceed >= <insert_some_enterprise_threshold>
Descript : Unit tests are either lacking or need to be refactored for a given application. This is needed to not only meet Enterprise coverage requirements, but also expedite the productionization and deployment of our application and avoid delays or stalls in the build stage and the release stage of our team’s deployment pipelines.
Task #1 : Bolster test coverage for microservice <A>
Task #2 : Bolster test coverage for microservice <B>
Task #3 : Bolster test coverage for directory <C>
Task #4 : Bolster test coverage for file <D>
Points : Five

I’ll put the user story in the backlog and then delegate them off to junior engineers or mid-level engineers with bandwidth for the current Sprint or upcoming Sprints.

Personally, I think it’s both the de facto industry-standard way and an effective way to onboard² engineers. I used it before when I was a senior engineer ramping up two junior engineers, and I follow this approach when I enter new codebases.

But why should junior engineers – or for that matter, newcomers – focus on unit tests? Why can’t they immediately dive into long-term feature or project deliverables?

• Industry codebases != undergraduate code bases – academia is hard, but in its own unique flavors ( it leans more theoretical ). But large-scale, industrial code bases are another leviathan . Navigating a monorepo with 1000+ LOC ( lines of code ) and learning how multiple components in a system move takes time. Even for a senior engineer or a staff engineer, it can take a solid one month ( or two ) to gain familiarity with a foreign codebase.
• TDD ³is a must-have skill to learn – academic settings emphasize writing code, but they seldom emphasize writing tests. Industry, on the other hand, emphasizes TDD. Getting junior’s acclimatized to writing tests helps them develop the right set of long-term habits.
• Facilitates codebase comprehension – writing new source code is hard, but writing unit tests in isolation or making cosmetic changes to code is easier. Unit tests can be written at the level of decomposed functions, and developers can leverage mocks or AI chatbots to write out the structure of tests. It’s quick to generate and test out a coverage report locally ( e.g. python3 run coverage report` ) than it is to make changes and test our source code deltas.
• Fast to deliver – each unit test itself is an isolated unit, as well as its associated file. Changing source code oftentimes introduces breaking changes across an application, but changing tests typically do not. Thus, its apropos for junior engineers, who tasks involve timelines which typically span from a week to a month.
• Testing helps developers understand what other developers were thinking – how can a developer quickly understand why a piece of source code was written? How can I quickly answer “why did we write what we wrote”? By looking at their associated tests. It turns out that tests quickly inform developers about the behaviors, the user inputs, and the end expectations that original code writers desired seeing.

1. Credit due to engineering talent at Google who taught me about writing solid unit tests and test fixtures – both explicitly and implicitly. ↩︎
2. Do correct me if I am mistaken here 🙂 ! ↩︎
3. TDD – Test Driven Development ↩︎