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.

Implementation Synchronous and Asynchronous Test in TDD

After learning about implementation of integration test, my next task will be testing out concurrency situation, where ID increment behaviour upon user deleting existing data and adding new data at the same time. Test is done by implementing two different task function. The flows of tasks is controlled by using semaphore implementation which is WaitAsync() and Release().

Initially, I implement the asynchronous test by separating add data and delete data into two task. Then I create new semaphore instances of semaLock1 and semaLock2. Hence, I control the tasks using semaphore, start the test by implementing task as user’s control. task Delete start, Meanwhile, task Add will begin and end first before task Delete end. The test was partially successful as I successfully increment the ID. However, I am unable to perform the asynchronous test as the delete function throws out multiple exception, despite I implement try catch blocks.

After a long time of struggle, I seek help from supervisor and we decide to make it simple, and perform the test synchronously. The test is much more simpler, but it is sufficient to proof the behaviour of function as planned.

I also did test of deleting existing data and adding new add after in asynchronous way. Which it only requires me to use same function from last test, to decrement current ID when latest data is deleted, and increment current ID when new data added.

Lastly, what I am able to observe during these tests, is that semaphore provides a good control to manage the flow of codes, but it might put user into infinite loops whenever semaphore is implement wrongly. For example, when there is only two semaLock in my test, semaLock1.WaitAsync() and semaLock2.WaitAsync() would make both task waits for each other.