Although the Flatlist obstacle was hard to define and took a long time to get solved. I’ve gained a greater understanding of testing and its flaws as a result. Therefore, I can follow the test progress and attempt to create the optimal assertion more quickly than previously.
This week, I started with testing the more page components. I tested the primary UI elements and the manual scanning functionality. I can state that my unit tests are imperfect and disorganized, but I am working to improve them each time, which affects my upcoming tests.
After that, I moved to test other views. They share comparable components, thus I did not encounter as many difficulties as before. Mr. Peter often urges me to write a good description, and I have since understood that the structure of my tests has to be improved and more understandable. Consequently, I separated my tests into several ‘describe’ sections. For instance, the ‘Header’ section only contains unit tests for the header components.
While you interact with some page, you can easily tell that something is going wrong with the manual scanning input field. Accordingly, I managed also to fix that and create a keyboard toggle that works as a controller to prevent the virtual keyboard from automatically appearing.
Overall, I learned more and gained new experience with unit testing. By running tests, I consistently encounter new errors that require new solutions and provide me with fresh knowledge. Next week, I will do negative tests on previously tested components. Fixing the extra rendering times problem for other views is another task as well.
