Tag: tdd

Since I have completed the purchase invoice from both purchase order and goods received, I spent the week checking the codes, and finding bugs to be solved to ensure that the module runs as intended without any problems.

I also had problems with the quantity mapping, as the total quantity being mapped in purchase invoice from purchase order is not the same as the total quantity from purchase invoice from goods received line item. The error was because I was initially reading the quantity from purchase invoice line item and goods receive line item instead of reading from the same entity which is goods receive line item. Due to this, different total quantity was being displayed in the UI.

Next, I wrote integration tests for purchase invoice from purchase order and goods received. The tests included creating new purchase invoices, and loading the list of purchase invoices, as well as viewing the individual purchase invoices.

When writing tests, mocks are being used. Mock uses the concept of testing a unit of code which depends on a group of other codes, such that the code will be tested even though its dependent codes are not written or contain bugs. In this case, mocks act as a platform which provides the test with its all needed requirements and environment to ensure that it works and pass as intended.

I also learnt how to resolve issues in Git. Meaning that once an issue is assigned to a person, and it is solved, to resolve the issue on Git, comments such as Fix, Close and Resolve are written alongside to the issue number created, as well as the codes need to be pushed so the changes can be viewed and tracked.

See you all next week 🙂

Continuing fixing errors from the pull and merging of codes, a lot of changes have been made to ensure that the codes compile and align with the new project structure.

The tests that have been written previously for Purchase Order and Goods Received were in need of changing and fixing, as the code structure have changed, the tests also got affected, as a result, the test bases were in need to be checked and fixed, because when debugging the tests to see where the error lies, the debugger does not run through the test, meaning it does not go into the test method environment indicating that the error lies in the test base.

Another thing is the save changes during initialization. Save changes is set to true without using the newly added save changes which is equipped with audit, because we are just initialization and setting the environment, thus, we do not need to audit or check and keep track to see who has made changes to the codes.
When writing tests, the Linq property Single() cannot be used for entities that are equipped with more than one element, as in this case we are trying to assume that entity has only one value which is not true. Thus First() is used when we want to retrieve one element only.

After the fixing and refactoring of codes, the views of the purchase invoice module were not being displayed, due to 2 main reasons which were that the Region Manager for purchase invoice was not added, as well as I mistakenly created a new view and removed the prism:ViewModelLocator.AutoWireViewModel="True" which resulted in the pages not being attached to each other and hence cannot be redirected once requested.

In the view models, often the properties are assigned with two access modifiers. Properties with private access modifiers when used do not make any changes to the User interface, on the other hand, properties with public as their access modifiers when changed or used will make changes on the user interface.

These are the major things that have been learnt the past week. See you all next week 🙂

The week started by completing the conversion of parameters files into events by using the enum class.

Next, I created multiple tests for the my transaction function, which creates a new purchase invoice based on different services.

Unfortunately, I had an error with the previously created tested for my transaction function, as the SupplierId could not get updated, it was null, but I couldn’t find the way to solve it, only to realize later on with the help of my supervisor, that I did not initialize the SupplierId in the tests, because I thought by just initializing and getting access to the whole entity, it will automatically assign the SupplierId, which was obviously wrong and made the tests created fail.

I then started analyzing the aggregates in the project, and found myself not understanding the concept behind the many-to-many relationship between some entities in the project. With further discussion, the relationship was converted from many-to-many to one-to-many relationship, and due to this many changes were needed to made.

Among the changes done to the files, were to change the complete function in the transaction for the purpose of auditing. As well as, EventName, Time and UserId has been added to the service functions, for auditing purposes as well, such that the when changes have been made, the person who made the change, along with the time and the change made can be tracked. Thus, by making these changes new parameters have been added to the methods.

Previously, the services and repositories interface used to implement the IDisposable interface, but now a new interface has been created that implements the complete, commit and rollback functions, not forgetting that this new interface implements the IDisposable interface as well.

Lastly, an important thing I learnt from Git, is that Pull merges two coding files together, in other words, it adds the changes that have been in both files and merges them into one. Push, on the other hand, add the branch into the project but does not merge it.

That’s all, see you all next week 🙂

This week is also about UI.

I created a new button to separate the purchaseInvoice different options. One which focuses on purchaseInvoice from purchaseOrder and another from GoodsReceived.

purchaseInvoice from purchaseOrder creation is created completely in other words creating a new purchaseInvoice and GoodsReceived. However, when updating the tests created previously, the tests failed due to the supplier entity and supplierId being 0.

At first, I couldn’t understand the reason why it is zero, but with the help of my supervisor, I found out that my mistake was that I did not include the supplierId and entity nor did I map it to the purchaseInvoice.

I also created an integration test for purchase invoice from purchase order. This test is more into testing the UI of the system. Checking whether when the intended button are clicked they perform and function as required.

I was also exposed to adding relationships in the database. I mean, when I set relationships in the entities file, some relationship will get ignored or confused by the entity framework if not fixed and identified properly in the Config files. Such that relationships such as one-to-many and many-to-many need to be written in the config files, along with their foreign keys, to ensure that the relationship is properly understood by the framework.

The main purpose behind using the Linq properties Include and ThenInclude is to ensure that the wanted properties to be retrieved are not null.

Lastly, I have refactored the codes in my module, such that all event functions are placed in the Events folder instead of Parameters folder.

When using the functions in the Events folder, I was introduced to using the enum, which is a special class that groups a group of related variables together. These, variables can be separated by a comma as follows:

public enum Level () { Low, Medium, High, }

The items in enum can be later on used or retrieved by using dot operation to get access to the enum class then the item.

Last week was a merge of creating tests and starting UI codes.

After so long, I was done with writing tests. I had a better understanding of how tests work, and refactoring codes as well. Moreover, I was exposed to not writing hard coded codes.

After 7 weeks, I can say that I have learnt a lot about TDD and EF Core, which is something I was not exposed to during my studies and this is something that would definitely benefit me.

Collection and Lists might sound the same, but collections are preferred over lists due to their ability to group outputs. In other words, List does not provide the feature of grouping.

For the past 3 years, I had the idea that the difference between void and static functions was related to having returns.

Little did I know that the static functions and variables are like global variables that can be used across the files, and when a method is static all its members should occupy the word “static” as well.

I have also read about bindable base which is an implementation of INotifyPropertyChanged interface in C#.