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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n","protected":false},"excerpt":{"rendered":"
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 … <\/p>\n