Guess What

Heyyyy, it’s me again and this week, I’ve come with new things to share with you all!

Well, I would say that my performance this week was way better than last week. Just imagine, during the first week, when I used to look at the pile of codes and scroll through them, my head spins and I start seeing things in two, hahahahaha, okay I’m exaggerating, but honestly, it was so much to swallow and understand especially with the fact that this is my first time to literally get exposed to these things, everything is brand new to me.

Firstly, I tried to use input binding in resource dictionary but still couldn’t do it, because the problem was raising from the data context, the resource dictionary was not able to get access to the data context of the file which contains the definition of the commands. Then, I tried using the data context concept but still no success. So, I asked my supervisor to move on, yes I did told him that, because I was already losing interest in doing the same thing over and over again. So, I was asked to write a test for the Escape key, well I would say that I only managed to do 50% of the task, I also learnt the difference between Setup and Verify when using Moqs.

Before having a look at the difference between Setup and Verify, a simple definition that can be given to Moqs is that they are objects which mimic or copy the behavior of a class or an interface and allows methods in the test to interact with them as if they were real. Hence, Setups are usually associated with the fact that we set a method and invoke a return that we expect to be returned when the method has been set up or initiated. On the other hand, verify deals with the concept of ensuring that a certain method gets invoked when the requirements are fulfilled, such that we want to verify that when method A is invoked B should be returned, if B is not returned hence our test fails. Unfortunately, the test I wrote was only for checking whether the command gets executed or not, but not whether the escape key was pressed, because the definition of the key was written in the .xaml file not the .cs file.

Next, I was given a new task, in which I had to create a module for invoices which is related to a system being created. I’ve also updated my dictionary of definitions, so initially I had the idea that data context meant giving access to the data in other classes when in reality it means a network connection created among data points in files. I have also learnt that the .sample files extension in projects are not supposed to be deleted but to be kept and used for references.

Lastly, I have also created tests to test the data being saved into the database. Basically, the tests I wrote were to ensure that the data types assigned to each attribute is correct and is the data type required, meaning a test method is written to check whether the attribute name is assigned a string data type, if the name is not assigned to string then the test fails, because the actual and expected data types are not the same.

Basically, that’s a summary of all what I did, see you all again next week. Make sure you read my upcoming blog, which is surely to be filled with new things to learn 🙂

Dispatcher Interface for Mocking

As I’ve wrote the integration tests for the pick module which also included the multi-threaded class, I’ve faced problem that the dispatcher in the multi-threaded class fails to mock. Since the multi-threaded class is used to refresh the data grid view within time interval, therefore fails to mock had caused all the integration tests fail to receive the data grid binding source to perform testing.

In order to solve the issue, I’ve decided to use the solution which is implement an interface for the dispatcher for mocking.

I’ve created the interface which called IDispatcher which include the BeginInvoke method. Then, instead of calling dispatcher, I’ve changed it to fire IDispatcher and its method as well. Lastly, in the integration tests, I call the mock for IDispatcher and setup its callback as (Action a) => a() to invoke the method in the multi-threaded class.

Refactoring code based on Integration Tests

There is few thing had been done, as shown as below that involve Test-Driven Development (TDD):

As some of my repository integration tests failed, I then refactor/alter my existing implementation of updating database from ReadData to GetData. ReadData in repository class has AsNoTracking(), where entity will not be tracked. When we make changes on the entity and will not be updated anyhow after calling context.SaveChanges(). By changing to GetData which allow entity to be tracked and any changes will be updated upon context.SaveChanges(). It also make sure latest data been retrieve after they are changed.

There is many repository test been done such as should add new, should update, should remove, should throw error, should roll back. I make sure these context integration tests passes and proceed to ViewModel classes tests. Following tests is mainly to make sure my implementation works fine under multiple scenario.

Most existing ViewModel integration tests failed as refactor of initialization is needed. ViewModel tests passed after few initialization, however there is few test involving DialogServiceMock failed to launch action of dialog in ViewModel class upon debugging. Despite that, the particular scenario works well when I run the application. Therefore, I need to figure out the factor behind failure of my test.

Fix Multiple Bug on Database & EventAggregator

To begin the week, I faced database bug without any error prompted. When updating my data on existing database, UI/ViewModel seems like it saved the latest changes. But when data grid list is refreshed, the edited data will be removed. After perform an integration test and run debug mode, it appears to be attribute is not sync with correct variable. Hence, causing the new set of data are not able to update. Beside that, old set of data is removed due to implementation to remove existing set of data after they are edited.

Next, when two or more user is using the application, concurrency situation will occurs. Hence, a test is performed to solve this situation. Updating data list might fail whenever the data on database and ViewModel selected data is differ. After test is done, I implemented a dialog box to notify the user when their data changes failed. Despite that, context is not reload to latest data list, thus, the error dialog kept prompt as I try to update new data. Therefore, I implemented a reload function in repository class to make sure latest data is reloaded whenever data update is failed through error handling.

Other than that, I found a bug in my implementation, everything works fine until I close the window and reopen it. By doing that, It would prompt error of “Invalid SelectedId” or “Object reference not set to an instance of an object” when I try to edit/delete selected data. It appears to be an issue of event aggregator been subscribed twice. By adding a dispose( ) function and Unsubscribe event upon closing the window, the issue is solved.

Implementation of Pick History View

For this week, a new feature which is the pick history view is implemented for the pick module. As what it named, it is used to view the pick history for specific line item. On line item selected, it will parse the line item id through publishing the event. While the pick history view model will subscribe the event and load the pick history with the selected line item id to filter the pick history that belongs to the line item.

Furthermore, I’ve also implemented the filtration of sales order by its pick status. Two checkbox is added to the view for user to select the type they wish to filter the sales order in different scenarios.

Lastly, I’ve conducted the integration tests for pick module in order to test out the concurrency situation will prevent the data to be entered into database and will rollback the transaction.

Combo Box Implementation & Dependencies Issue

I create an implementation of “Terms”, which means setting a fixed or limited period for something. Implementation is based on previous implementation as example. In this implementation, I learnt that we can code a grid list in combo box other than normal list.

Next, I was told to alter an entity from 2 decimal places input to 3 decimal places input. It has to be alter to match certain Unit of Measurement.

Major issue that I faced is the project dependencies is directly linked to one of my project dll file. This has restrict me from debugging due to built system ignored current code I am working on. After going through possible problems, the system does not works as how it suppose to be. In the end, the problem solved by moving the dll file into “Projects” child under dependencies.

Lastly, after the dependencies issue being solved, I now face new problem in the module I am working on. The module does not save certain entity into the database. Therefore, I will need perform multiple test to figure out the problem.

Altering Tests based on Database Changes & Testing New Interface

I added new entity into existing database migration, and update stored value in database. Due to new entity is added, most unit tests and integration tests failed. When put those tests to debug, It appears that there is database type of exception. Hence, I need refactor existing Test Base by adding value for new entities in order for tests to assert properly.

After that, I get to play around with new interface and get familiar with it implementation. The implementation are the use of Regex, Unit of Measurement for calculation in system. Also, implementation of combo box, search bar, CRUD and data injection from few other MVVM services for functionality in system.

Utilizing EF Core Exception Handling & Debugging CRUD methods

I continued my progress with fixing delete function, which suppose to remove linked data in multiple table across the database. The failure of delete function due to certain entity are set as foreign key of other table. This problem is solved by setting null value for related foreign key in delete function. As the value of foreign key is null, deletion is allowed as how it suppose to behave.

Next, I alter sequence of textbox in View class. To ensure best user experience when they uses hotkey “Tab” to navigates over to next textbox available.

Then, Remove validation made in ViewModel class and implement it in repository class. Allowing EF core throw error whenever unique entity is input multiple time. The error will be catch, hence, prompt dialog box to notify user of application. This way is a better implementation reduce number of code, however it cause few issue in application. Issue such as user unable to create new user after error popped up to indicate similar user id appears in database.

In conjunction, RepositoryActualDbTests class is created to mock my situation. I arrange declaration, execute three seperate input ( 1st input : id = 1, 2nd input : id = 1, 3rd input : id = 2 ) , and assert expected behaviour ( Total of 2 input should be saved input database ). After quite an amount of testing and struggling, the bug is then fixed, however it requires chain fix in code. Therefore, my supervisor advice me to try out a different implementation for my create function by mocking a test.

Validating and Granting Access Rights

For new context and module added last week, I imitate some tests from example code provided and add few new tests. I also create some class to build dummy database to ease unit/integration testing. After going through some tests, I found out error when deleting data. Upon deletion, only data from 1 table is deleted, delete function suppose to remove few linked data across the database.

Before I look through into bugs of deletion, I make new implementation to validate user input in required textbox. If textbox is empty for non-nullable textbox, I create validation for system to prompt warning dialog to notify user. such as below :
if (string.IsNullOrEmpty(Wrapper.Variable))
{
_dialogService.ShowDialog( n, p, r );
return false;
}


Besides, Admin role is added to alter availability of buttons in system. I was been told to make initialization of adminUser as variable. Variable adminUser is set to bool = false initially, and will be implement in feature implementation. If bool adminUser = true, user is an admin user; bool adminUser = false, user is normal user. The reason of adding in admin role is to restrict some functionality of normal user. For normal user, the system will hinder user from edit or delete data in the system. In significant, admin user will be granted privilege to edit and delete.

Implementation Synchronous and Asynchronous Test in TDD

After learning about implementation of integration test, my next task will be testing out concurrency situation, where ID increment behaviour upon user deleting existing data and adding new data at the same time. Test is done by implementing two different task function. The flows of tasks is controlled by using semaphore implementation which is WaitAsync() and Release().

Initially, I implement the asynchronous test by separating add data and delete data into two task. Then I create new semaphore instances of semaLock1 and semaLock2. Hence, I control the tasks using semaphore, start the test by implementing task as user’s control. task Delete start, Meanwhile, task Add will begin and end first before task Delete end. The test was partially successful as I successfully increment the ID. However, I am unable to perform the asynchronous test as the delete function throws out multiple exception, despite I implement try catch blocks.

After a long time of struggle, I seek help from supervisor and we decide to make it simple, and perform the test synchronously. The test is much more simpler, but it is sufficient to proof the behaviour of function as planned.

I also did test of deleting existing data and adding new add after in asynchronous way. Which it only requires me to use same function from last test, to decrement current ID when latest data is deleted, and increment current ID when new data added.

Lastly, what I am able to observe during these tests, is that semaphore provides a good control to manage the flow of codes, but it might put user into infinite loops whenever semaphore is implement wrongly. For example, when there is only two semaLock in my test, semaLock1.WaitAsync() and semaLock2.WaitAsync() would make both task waits for each other.