Month: December 2022

I started off the week by adding more test cases for the Update command, observing the update logic in different scenarios. Found out there was a bug in the Update logic which was allowing the code to update the line items with Ids that were already taken before and also which did not yet exist. 

After some brainstorming I was finally able to fix the bug. I added a piece of code which acted as validation for Ids. It would throw an error if the LineItem Id that was provided was not present in that retail order.

Next, I got a new task to add a new field of Order No which was to be generated by a sequence generator. Purpose of adding this field was to give each order a distinguished identity, as we won’t be using their Ids as identification in actual business. Following this change I made changes to my Create command Handler so that now it creates a new sequence whenever an Order was created.

Now it was time to test my Create command which was modified with a new feature. I was able to successfully run 3 test cases, for the test cases I had to create a new Sequence Generator Id then pass it into the Create function which was then handled, by Create logic handler, and a OrderNo would be created. To test if my transaction which I added last week, I created a test case that would fail and observed if the transaction rolled back to the last savepoint.

Had a problem with validating the Sequence Generator Id as it was optional to input when there is no Id created, after discussing with my supervisor we came to the conclusion to not include a validation for the Sequence Generator.

Furthermore, I wrote test cases for Update command testing the Order No update and altered the DTO of Get query to output the Order No to the user.

Since a basic model of API was done, I was introduced to new tasks and features to make the API more robust.

After finishing the design of the UI for the stock take feature, I went and started with the logic of the code which will handle the API calling. The detail page of the stock take will display the stock take together with its line item. This is done by calling the get stock take by id query. In this detail page, the user can create a new stock take and also updating together with deleting existing stock take.

After completing the detail page of the stock take, next is the list of the stock take which will display the list of existing stock takes. In this page, the get stock take list query will be used. Not only that, the user can also the set accept the stock takes through this page. This is done by allowing the user to check on the existing stock takes and clicking on the accept button.

Lastly is the accept part of the stock take. The accept button will use the accept of the stock take API. When the user set accept the stock take, a progress bar will be display to the user. As of currently, the progress bar is not working properly will need to be fixed.

This week I had only one major objective, which was to complete the new Stock Take module.

After constructing the detail view layout last week, I began this week by creating the layout for the Stock Take list view. The List view will display all of the created stock takes. However, as no data had yet been received from the API, I had to continue developing the detail view.

Furthermore, I needed to retrieve data from the API in the detail view.
It took me quite a while time to input the data and review the list of stock takes. One major issue I had was that I couldn’t make a successful Post request to create the stock stake and kept failing at it. One of the reasons was that I had no validations for the barcode and other data.

I was able to create the validators. By doing so, as well as accessing the API to retrieve item data, I was able to debug the problem more easily than previously. Furthermore, it took some time for me to create the POST request and ensure that the data was correctly sent to the database.

Continue back to the list page, where I was able to access the list of created Stock takes after successfully retrieving the data. In addition, I wanted to utilise the getStockTakeById request to view or modify a particular stock take. And after some effort with the code, I was able to successfully get it to function, allowing me to access the stock take and make any changes.

By the end of the week, I believed I was nearly finished since it appeared functional to me. However, because of a conflict with the API, I was required to map the data manually from one type to another. This was totally new to me since I had very blurry vision on it, studying that and implement it correctly is the next thing to do.

I spend my third week mostly working on a complex command Update and fixing bugs in my code.

I started off the week by adding more test cases in the Repository test file, the purpose behind this was to test if my repository is correctly performing the CRUD operations. After this, I realized that I’m yet to write test cases for data which should have been done once the entities were created as these test cases help ensure the data type of each field is consistent.

Next, I shifted my focus to correctly format my API test cases, of Create and Delete, according to the norms of 3 A’s which are Arrange, Act and Assert. Moreover, I improved my test cases by adding more assertions. 

Finally, I started on coding the logic of the Update command which was challenging because Updating every field can have multiple possibilities.

After coding the logic I realized there was a bug which was occurring when an existing line item was removed and a completely new one was added. Once the bug in the UpdateHandler was fixed, I added the controller which handles the whole PUT request.

Lastly, I moved my focus on testing the Update Command. On running the test case gave me an error report ‘database operation expected to affect 1 row(s) but actually affected 0 row(s)’ error. After a lot of unsuccessful debugging I finally sought help from my supervisor who helped me find the bug and explain to me the root cause of it. This error was due to the primary key which I was hardcoding inside my update logic. We are not supposed to set the primary key as the database does it for us automatically.

After finishing the accept command of the stock take, The logic of the accept command is then registered as a background service. When the user send an accept command, the API will return a Guid back to the user. The user can then use this Guid to query the status of the ongoing accept command of stock take. The progress of the ongoing accept command is stored in a concurrent dictionary.

From there, the user will use the Guid to query the dictionary and get back the status of the ongoing accept command. After a small discussion with Mr. Peter the query of the status of the accept command should provide more than just the percentage of the ongoing accept command.

Lastly, after finishing the API component of the stock take, I will move on to doing the UI of the stock take using WPF and the MVVM pattern. Firstly, I will create the rough design of the stock take UI and afterward I will implement the logic. Currently I’m doing the design for the details view of the stock take.

I spent my second week working on the coding side of the Retail Business which was briefed to me last week.

I started off the week by setting up my workspace, SQL workspace and Source Tree. Moreover, I concentrated on learning how a test case is executed for an API, for example; how handlers work , repositories, entities, and also how to debug a test case. 

Next, I was given my first task to create an API with simple entities and test cases. I kicked off the API by creating entities with relevant fields and also their config file which helps mapping entities and their properties and relationships to a relational database. Once the fundamentals of the entities were created, I shifted my focus towards the commands and query aspect. Started it by defining repositories, updating the Database context file and adding dependency injection. 

Furthermore, I completed the Create and Delete commands with successful testing and made relevant commits. Moreover, I finished the Get query with test cases which was not until I had to fix some bugs in my Data Transfer Object (DTO) file. Lastly, I finalized data testing which tests the logic of your repository and started building logic for the Update command.

As for the final part of the command for stock take is to allow the user to be able to query the status/progress of the ongoing accept command. This is done through the use of concurrent dictionary. The dictionary will hold the value of the progress of the accept command and return it to the user.

Next, I need to create a background service for the concurrent dictionary so that the value can be display to user. To do this, I have to create monitor class to monitor the dictionary and check if the key for the dictionary exist which in this is a Guid. After that, the progress of the accept command can be display to the user. After creating the monitoring class, I have registered it as a singleton in the source code.

Currently I’m still trying to figure out on the logic of the monitor class which will check the dictionary every 5 seconds and report back. I’m also trying to figure out on how to return the value in the dictionary to the monitor class to be presented to the user.

This week was essentially a continuation of last week’s work, for which I needed to fix errors and improve the logic. Some critical bugs were reported that required immediate attention. Changing the Focus logic in the Decimal Text Input component and failing to write a correct test script for the Combo TextBox component. That what mostly happened during this week, and what I’m going to talk about in this blog.

First, I got complaints about some bugs after patching the last update. Such as, Undo operation, was not working after searching and selecting a customer. Another bug was that when processing order with multiple line items, the app didn’t navigate to the second item after processing the first one. Next, with Mr. Peter’s guidance, I found that most of the bugs occurred because of the warehouse identifier, which was hardcoded in many places in the code, so altering that fixed the problem.

After that, I worked on fixing the errors with multi-line items. On the other hand, this caused another issue that occurred whenever a single object was processed, as the rendering time was around 5 seconds. The bug was addressed by modifying the reset box code so that it would only operate with multiple items.

Modifying the focus logic in the DecimalTextInput component was also done this week, where I fixed the bug with the OnBlur property. And I created a unit test for the component to ensure that the input number will always round off based on the specified decimal places. On the other hand, I have been searching and trying different ways to run a correct test for the Combo TextBox component. Most of the ways I found were always getting me a pass result even if the test should be fail. I also came across several techniques for testing that mock the “focus” but unfortunately, those also didn’t work for me.

In conclusion, this week was consumed by fixing the issues raised following the last deployment. Fixing the decimal component focus and doing a test for it, but not conducting enough testing for the combo component, where this and other critical issues will be addressed next week.

I spent my first week at the company mostly concentrating on learning some softwares and understanding the fundamentals of the task I would be doing during this internship.

I started off the week by learning git immersion. Using Git I learned how to create repositories, commit changes, merge repositories, and push any changes made in the repositories using the git commands.

Next, I was briefed on the area I would be focusing on during the internship which is the API. After grasping the structure and the business rules provided to me I extracted out entities, fields and relations and came up with a Crow’s Foot Notation (CRD) of the business. Verification of payments was a challenge I faced while forming the CRD, as there are multiple means of payment with possibility of multiple transactions. However, after having some productive conversations with my supervisor I was able to finish it.

Lastly, I was introduced to the Stocks API code since I would be creating a API therefore going through the Stocks API would really help me understand the concepts and fundamentals of RESTful API and how to test it using Test Driven Development (TDD).