Mock Implementation in Testing

Hello there, hope you have a nice day. It is time for my weekly task update. For the past week, I have been working on to implement mock for the test cases.

First and foremost, what is mock? Mock in software testing is an object that mimics the behavior of a real object in a controlled way. Next, mock also is a process used in testing when the unit being tested has external dependencies. In addition, the implementation of mock used to test the interaction between objects and simulate certain conditions that might be difficult or impossible to reproduce in a real-world environment. Mock functions used to test the links between code by erasing the actual implementation of a function. Next, it use to capturing calls to the function. Other than that, capturing instances of constructor function when instantiated with new.

Next, for the first mock implementation, I tried to implement mock in focus. For this test case, the purpose is to mock the focus method of the element and triggers a focus event on it. Then, for the next test case, I tried to implement mock for React Navigation. For this mock implementation, I have been using spread syntax to replace the navigation method. The spread syntax is a syntax for copying the properties of an object into a new object. This is crucial in testing to make sure the original item has not been altered.

Overall, I want to thank Peter for his advice and the opportunity to learn more about the use of mock tests in testing. Despite the fact that it can be challenging for me at times, I am eager to keep growing and learning new things.

Tough Tests before starting The Stock Take

This week was mostly focused on developing test scripts for the Stow List UI and building the Stock Take UI. Stock Take is the new module on which we will concentrate in the coming days.

The first thing I did this week was use Mr. Peter’s provided examples to write some test scripts. I created a script to verify that the Text Input resets to a blank state after an incorrect input. The test was more difficult than usual, and I ran into several problems while completing it. The fact that we are developing an asynchronous code is the primary cause of the difficulty, and it is often the reason why I am unable to locate the source of a particular fault.

The next thing I had to do was mock the Dto, which was not easy. It should have functioned after that, but it did not. Moreover, I started debugging the test script with the code under test, but I failed to run a proper test. eventually, it was caused by the timer that I needed to stop the timer in order to finish my test successfully.

After that, I was also unable to complete a separate test script that validated the “back” button. It took a lot of my time, and I did everything I could think of to mock the BackHandler, but it was difficult. In the end, I got through by using “/ @ts-ignore,” which tells the TypeScript compiler to disregard the line below it and skip over the error. And thus, the mock worked and did its job and I was able to finish my test successfully.

Finally, I began to create the new layout for our new module. I designed the main UI components. For the first time, I used new components such as a SelectList and a checkbox. Next week, I’ll get the data from the API and continue working on the stock take, which has to be ready to go by the end of the week.