Hello, my name is @masa, and I am a first-year graduate student at Kyushu University.
I did a two-month frontend engineer internship at Mercari, working on Mercari Hallo, at the end of 2024.
In this post, I’ll talk about my area of interest, strategy for integration testing, and what I learned at Mercari during my internship.
Why I decided to do an internship to work on Mercari Hallo
My main goal of doing an internship working on Mercari Hallo was to experience service development for a large-scale service, particularly a consumer-facing service. Mercari Hallo is one of Mercari’s services and was released less than a year ago, so it is still a relatively new product. Working on Mercari Hallo provided the perfect opportunity for me to learn about practical development processes in a field that demands speed and quality.
Another reason why I chose Mercari was to gain first-hand experience of Mercari’s workstyle and culture for a better understanding of how such a company operates.
Initiatives for integration testing
During my time as an intern, I worked on different tasks of different sizes. One project I was particularly invested in was integration testing for business-facing UI screens. When I joined, the team had already determined which technology to use and had finished creating the development environment under the guidance of our tech lead @ryotah, and was just about to start working on improving test coverage.
At the time, integration tests for Mercari Hallo were performed one page at a time based on specifications, using frontend testing methods previously used at Merpay. I worked on the following two improvements to this process:
- Avoiding bloated code
- Optimizing validation testing
Avoiding bloated code
Writing tests according to the specifications ensures consistent test granularity and policy throughout the team. However, sticking too closely to the specifications means that, for example, the same code is written to validate the same form components on different screens, which tends to make the code bloated.
To solve this problem, we considered the following three approaches:
- Write tests for shared components
Advantages: The problem of redundant code can be solved. The same test can be used for shared components, which means that there is no need to write the same validation logic over and over again.
Disadvantages: Taking this approach would deviate slightly from the "test in a way that’s close to how the application actually works" policy for integration testing. There is also the concern that different people will write tests in different ways if complex portions are treated as components. - Writing one test for all screens
Advantages: With both of these intermediate approaches, developers write code that is faithful to testing based on the specifications, which were written with how users will actually use the page in mind. Because of this, it is easier to notice slightly different use cases and bugs.
Disadvantages: Writing a large amount of similar test logic makes editing that logic a big job and maintaining the code difficult. - Write tests for shared components on one representative screen
Advantages: With the two intermediate approaches mentioned above, it’s possible to maintain basic functionality while keeping test redundancy to a minimum.
Disadvantages: This approach is not completely comprehensive, so it may be necessary to write additional tests for other pages.
In the end, we decided to write tests for shared components on one representative screen and write additional tests only when there is page-specific logic. Considering team resources and development speed at the time, we determined that this was the most realistic and flexible approach.
Optimizing validation testing
Unit testing covers standard validation using the form library (react-hook-form), so for integration testing, we focused on any parts that are difficult to validate with unit testing.
For instance, schema testing using react-hook-form alone cannot cover the logic that displays a modal when there is a submission error, as shown below.
const onSubmit = (value) => {
// if input field contains an error
if (value.name !== 'hoge') {
setShowModal(true)
}
// data transmission, etc.
}A part like this can be validated with an integration test using Playwright.
// Example of integration test using Playwright
test('display modal if input field contains an error', async({page}) => {
// omitted
// ...
await page.getByLabel('name').fill('foo');
await page.getByRole('button', {name: 'send'}).click();
await expect(
page.getByRole('dialog', { name: 'include keyword in name' }).toBeVisible();
});I made sure to balance the cost and ROI of writing test code and write meaningful test code that doesn’t create any technical debt.
Also, to increase transparency and efficiency of the development process, I created a Slack channel for integration testing. I created this channel because there wasn’t really anywhere to ask for advice about technical issues in the frontend domain, and because there were few opportunities to communicate with engineers in other teams. In this channel, we could share any questions we had or specific problems we faced during implementation, which led to a shared sense of problem awareness across the team and helped us find better solutions.
Other activities and experiences
During my time as an intern, I also participated in an ideathon aimed at improving the efficiency of work using generative AI.
In the allotted 90 minutes, I worked in a team to come up with ideas and even create a prototype. While the schedule was very tight, it was a very exciting and fun experience.
When choosing which idea to present, we focused on whether other people experienced the problem we were trying to solve and whether we could achieve a result in a short amount of time. In the end, we went with an idea called “C’mon, Calendar!” which aimed to streamline scheduling on Google Calendar based on participants’ availability and the type of events people want to add.
Everyone on my team was so talented, and I struggled to see how I could contribute at first. Focusing on my strengths, I decided to create the workflow and handle implementation. We wanted to get the prototype to a point where we could use Zapier to retrieve calendar information, but unfortunately we ran out of time.
I’m pleased to announce that my team won the ideathon! 🎉
(Thank you to all my team members! 🙇♂️)
Difficulty communicating in English
When I interviewed for the internship, I was told that the team I would be joining did not use much English so I didn’t need to have strong English skills. However, between that interview and me joining the company, some team members changed, and I had to participate in a weekly all-English frontend engineer meeting from my very first week! I was worried about being able to communicate in English, and I really struggled when I had to facilitate the meeting in English. I used cheat sheets and other tools to help me get through.
Mercari has a lot of non-Japanese employees, so I had plenty of opportunities to use English when attending events at the office. Also, pull request reviews are made in English, so I got to experience working in an English-based environment.
At first I was taken aback by how often I had to speak English, but being in that environment really motivated me to study more. Working somewhere that improved both my technical skills and global communication skills really helped me grow as an engineer.
To conclude
Through my Mercari Hallo internship, I was able to gain a lot of valuable experience in the field of large-scale service development. Implementing integration tests in particular gave me great insight into how to write high-quality and effective test code and the importance of team communication.
I feel that the knowledge and experience I gained over those two months will serve me well in my future studies and career. Lastly, I’d like to thank my mentor @d–chan and everyone who welcomed me to the company.
