This week was another productive part of my #100DaysOfCode journey, with a mix of learning, revision, and building.
I started the week by going deeper into software testing with JUnit 5, exploring advanced features such as dynamic tests, parameterized tests, test templates, dependency injection, and JUnit's Extension Model. I also learned how JUnit 5 integrates with tools and frameworks like Mockito, Spring, Selenium, and Cucumber.
I then spent time revising test case design and testing management, covering topics such as test planning, test fixtures, equivalence partitioning, boundary value analysis, code coverage, TDD, BDD, continuous integration, and testing pipelines.
One of the biggest highlights of the week was completing my Mastering Software Testing with JUnit 5 exam, where I scored 70%. It was a valuable learning experience, and I'm taking the lessons from the course forward as I continue improving my Java and backend development skills.
After completing the course, I shifted my focus toward building. I started a new portfolio from scratch using Next.js, Tailwind CSS, and Motion, where I worked on the Hero and About sections.
Alongside the portfolio work, I also started reading Introduction to Docker and began refreshing my understanding of containerization.
This week reminded me that growth as a developer isn't only about learning new technologies. It's also about revising what I've learned, putting it into practice, and continuing to build.
With only a few days left in the challenge, I'm focused on making the most of them.
As part of my #100DaysOfCode journey, I continued learning JUnit 5 and went deeper into how testing works and how JUnit helps developers write, organize, and maintain tests.
At first, testing can seem straightforward: write some code, create a test, run it, and check whether it passes. But as applications grow, tests also need to be properly organized and managed.
This was one of the things I started understanding better during this part of my JUnit 5 learning.
JUnit provides annotations that allow us to run specific pieces of code before and after tests.
@BeforeEach — runs before each test method. @AfterEach — runs after each test method. @BeforeAll — runs once before all tests in a test class. @AfterAll — runs once after all tests in a test class.
For example, if multiple tests require a particular object or resource, instead of repeating the setup inside every test, the setup can be handled using @BeforeEach.
I also learned about the test instance lifecycle and the @TestInstance annotation.
JUnit 5 normally creates a new instance of the test class for each test method. However, @TestInstance can be used to change this behavior.
This becomes particularly useful when working with shared test state or when using lifecycle methods such as @BeforeAll and @AfterAll in certain situations.
It was another example of how JUnit 5 gives developers more control over how their tests are executed.