From the first day, Mr. Peter pushed an updated version to fix the configuration error. He also assisted me in modifying the testing environment to make it more understandable and efficient. This included improving the controller naming to reduce confusion. In addition, based on our last discussion, I redesign the schema to reduce the number of objects for better efficiency. I rename the item details for clarity and soon update the relevant transfer services and initialised test data. Then, I proceed to conduct transfer tests for the all the processes, as well as initialised more transfer and item data. I also updated the item configuration to ensure unique data for each record so that I could proceed with my tests. Meanwhile, Mr. Peter mentioned that transfers would occur only in MongoDB, without SQL database involvement. As a result, I remove all references by excluding the “Mongo” naming of transfers. He also pointed out that the initialisation for stores and items should not happen multiple times. Furthermore, Mr. Peter suggested adding error tests to account for missing item required in specific parts.<\/p>\n\n\n\n
Besides that, I continue working on transfer order tests as well by adding more possible error tests. I also implement public static methods for initialising store data. After that, I continue on completing the logic for creating and canceling transfer DO. Soon, Mr. Peter reviewed my tests, he then found out that there are some item data referenced with many tests which cannot be ignored. Mr. Peter stated that each item data should only be used for one test. He then suggested if this intialised data make confusion, it is better to separate the controller test with different part. He also recommended that error messages should not be hardcoded but should be added to the ErrorMessage class instead. Additionally, he advised moving the transfer files from the “Orders” folder to the “Transfers” folder for better maintainability. Mr. Peter highlighted that using barcodes to identify specific line items is unacceptable since the orders might have duplicate item orders. So, I decided to use the “No” attribute for uniqueness. Mr. Peter also suggested creating tests for failure scenarios when I have free time. Mr. Peter also emphasized that on every error tests, there will be no updates occur on the collections where proper assertions are necessary. <\/p>\n\n\n\n
Moreover, I focus on hardcoding the transfer order error messages and updating the assertion tests for throwing errors. Once all the tests passed successfully, I then continue on the transfer DO by updating its service and restructure the transaction logic for both transfer order and DO. Next, I begin working on transfer DO tests by referring to the transfer order tests. I initially initialising data with another transfer DO data and I start the tests for the create command. Later, Mr. Peter mentioned that using “No” for the line item could be risky and recommended using the ObjectId for each LineItem instead. He then reviewed the line item schema and suggested moving it into its own transfer file. Mr. Peter also reviewed my logic and pointed out confusion in handling multiple exception catches. He advised changing exceptions from Exception to InvalidOperationException or removing additional exceptions entirely for clarity. <\/p>\n\n\n\n
Apart from that, I replaced the “No” input with LineItemId in commands, services and tests. To ensure that the ObjectId data could pass tests, I request my friend to send me the relevant ObjectIdConverter file and updated the startup to support serialisation settings. After successfully completing the transfer order tests by adding another throw error tests for LineItemId, I continue on creating the error messages for transfer DO and add them to error assertion tests as well. Once the create tests were successful, I move on to the cancel tests. Mr. Peter reviewed my transfer work and suggested amendments to the transfer schema for better maintainability by reducing the number of objects. He questioned why data instances were used instead of utilising the TestFactory class, so I update the implementation. During the discussion, the offsets should be handled during transfer receive and I understand role of transfer receive. I then pushed my changes to my branch, and the suggestions and additional requirements from Mr. Peter will be addressed next week.<\/p>\n\n\n\n
Overall, I feel a deep sense of growth and accomplishment as I tackle complex technical challenges. The journey has been enriching and fulfilling, motivating me to continually strive to improve while appreciating the value of teamwork and mentorship.<\/p>\n","protected":false},"excerpt":{"rendered":"
From the first day, Mr. Peter pushed an updated version to fix the configuration error. He also assisted me in modifying the testing environment to make it more understandable and efficient. This included improving the controller naming to reduce confusion. In addition, based on our last discussion, I redesign the schema to reduce the number … <\/p>\n