We tested our application frequently to check if it was working. We would test every time after we make a change to the code, no matter how small the change is. This would allow us to prevent heavy backtracking when there is a bug in the program.

Every time we add in a new feature, we would always test the old features to see if they were broken by the new feature. This would save us a lot of backtracking trouble in the future and ensure that our application is reliable and stable.

Everytime there was a new prototype or a new feature is added, we would send it to each other and test whether if it works on each other's devices. This would increase the stability and reliabiliy of our project as any bugs would be found quickly and easily.

Using test driven development helped us a lot by decreasing the amount of time we spent on debugging averagely. It also lets us know whenever an old feature is broken by the new code we added.

Instead of always compiling the APK to test on our UCL borrowed android phone, we decided to test in virtual environments. We would use the Unity's in built virtual environment for android devices to test. This would significantly reduce the testing time as you do not need to spend time transferring the apk to the test phone.

A virtual environment is used instead of using the actual android device to test

Compiling the application in Unity and testing it may be quite a tedious process. So we have made a dotnet application to do the testing for all the C# scripts that the Unity application will be using. This significantly cut down our development time as compiling the scripts in Unity will take quite some time and in some cases might hang the application.

Dotnet application running the scripts to test the C# functions that will be imported into Unity.

TDD, writing testing routes first before implementing the main functionalities. The home route was also part of the testing for the backend connection to the Azure blob storage. It returns a list of blobs on the blob storage, we tested this by manually adding files onto the blob storage and checking if it reflects on the list returned. Regression testing was also carried out when developing the upload function, we re-tested if the home route was working as intended after it was created.

Testing was first carried out through Remix; Remix has a decoded log input and output [Figure 1.1] that allows us to solely focus on developing on the smart contract without worrying whether the connection between the blockchain and front-end application is working. This saves us time by removing external factors that may cause errors during development and it decreases the amount of time spent debugging the solidity smart contract.

[Figure 1.1] An example of the debugging log of each transaction and function call carried out, this information is really useful for testing as it display the decoded input data.

We then carried out testing through Ganache, as Ganache [Figure 2.1] allows me to test my front-end interaction with the smart contract deployed on a local instance of a blockchain network. We did this before deploying our contracts on the Ropsten Testnet as it is a lot faster compared to the Ropsten Testnet, this is because there are only 10 nodes on the Ganache local blockchain compared to the large scale of the Ropsten Testnet.

[Figure 2.1] An example of what a deployed Ganache local blockchain looks like

We then further my testing by deploying our smart contracts to the Ropsten Test Network. The Ropsten Test Network allowed me to test my contact on a much larger scale that mimics the Ethereum mainnet closely without paying for real Ethereum as I can obtain Ropsten Ether for free through the Ropsten Faucet. This also allowed us to view our transaction through Ether Scan to validate that our transaction was successful [Figure 3.1, Figure 3.2]. We also carried out regression testing along with test driven development and frequent testing, every time a new feature was implemented on Solidity, it goes through the same 3 step testing stages before we deploy the contract onto the Azure Blockchain Service.

[Figure 3.1] An example of what a confirmed transaction to the Ropsten Testnet looks like on Metamask.



[Figure 3.2] The same transaction displayed on Etherscan. Etherscan also provides an extremely detailed report about the transaction containing information such as Gas prices which helps us during development.

◘ Whilst developing the smart contract on Solidity, it was important to test the functionality that was being implemented. The way we did this was to think of different types of test data to input when testing the functions we wrote. This involved thinking of valid test data, boundary test data and invalid test data.

◘ Firstly we will talk about how we tested the getter methods. This was quite straight forward, as we would first use the set function to push data for the test structure onto the blockchain, with a hash, filename, etc. In order to test this properly, we would push multiple files. We tested to ensure that when given a non-existent index that null values were returned, and when given the correct index, the appropriate data was returned, for example, the getHash function would return the hash at the correct index. To ensure this was working across all getter functions, we would provide the same index to the others and check that they returned the appropriate data connected to the hash at that index. This specific way of testing was useful as it helped us identify one specific bug that is unique to Solidity, which was related to mappings. Our Solidity code uses mappings which work in the same way as HashMaps, and something we discovered was that when a user tries to access a non-existent key on a mapping, the value returned is always 0. This caused issues as one of the mappings was used to store indexes where one of the values would have been 0, therefore testing helped us to identify and work around this feature of Solidity.

◘ The second thing to test was the setter method. This was also quite straight forward to test. The way we tested this was to pass through various different types of data as parameters through the function, including normal and erroneous data. We would then use the getter methods to check that what we had just updated worked, as the getter methods get the values that were set. We would often use the set method multiples times to ensure that it worked consistently for multiple pieces of data.

◘ Once we were able to ensure that both the setter and getter methods worked fine, this meant we could conclude that the solidity smart contract worked as intended, as they are the only ways of communicating with the contract.

We made sure that our React application had a responsive web UI that would adjust to different people's screens. For instance when one of us projected our screens out onto a TV, the application should still function properly and the UI should not be distorted.

Full Screen

Minimized

Left half of screen

1. There will be situations where our application will be under stress. This will happen when the file list is extremely long as this would cause it to load extremely slowly. At 27 files, it took approximately 33.91 seconds to retrieve the document list. However when the file list was as short as 3 files, it took approximately 1.73 seconds or it to retrieve and display the document list. One solution to this might be to optimise our smart contract, as well as change the approach we take when loading the document list. Instead of loading the entire list, we could instead just retrieve a portion of it. We are however unable to implement this due to the time constraints as we only found out that our application does not perform extremely well under stress at a very late date.
   
   The graph below shows how the time to load is affected by the number of files in the list.



2. We rewrote the front-end React application after testing as we found the user interface to be insufficient and also the waiting times for loading from the blockchain was too long. This rewrite resulted in faster loading times of files.
   
   The graph below shows how the time changed from before and after the change when 3 files were loaded.

1. User 1 Feedback: I think the idea of the project is great as I can understand how there are problems with the construction industry and how this project solves them. I thought the React App had a very aesthetic and user-friendly design which I found easy to use. I particularly liked that there were images for everything as this adds to the visual appeal and ease of use. I found it simple to interact with the Blockchain via the React app which is something I particularly liked as it simplifies the process of uploading and retrieving to the Blockchain. The Unity interface was also nice and quite simple to use, however, something that could potentially be improved is to make it slightly more user-friendly. Overall, I found it to be a pleasant experience and found it easy to use as someone with no experience with Blockchain or AR.




2. User 2 Feedback: As someone who has heard of the Grenfell tower incident, I agree that accountability issues in the construction industry is a big problem that needs to be fixed. I used the .apk and placed a few buildings, and I liked that there was a counter that kept track of how many I place. In the future maybe this could be developed to be more complicated. Interacting with the Blockchain via the app worked fine. The web-application had a nice design and was easy to navigate which improved the user experience. Overall, the project seems effective and has a very friendly user interface.