# **Project 1 Blog Post:**
#

:::info
# Project 1 Information:
This project is split up into 2 parts:

### Part A:
In short, the purpose of part A is to understand the purpose of the project and the code itself. Furthermore, it is also important as it ensures that our group is all on the same track about who's doing which test.

We also had to choose which tests we are going to create. I chose the following:

* com.gsd.algorithms.datastructures.dynamicarray.intArray.size() - 1
* com.gsd.algorithms.datastructures.dynamicarray.intArray.isEmpty() - 1
* com.gsd.algorithms.datastructures.dynamicarray.IntArray.get(int) - 1
* com.gsd.algorithms.datastructures.dynamicarray.IntArray.add(int) - 3
* com.gsd.algorithms.datastructures.dynamicarray.DynamicArray.removeAt(int) - 5

### Part B:
The purpose of part B was to actually write the Tests in our branch and then create pull requests to merge them into the main branch. The final version of the master branch should have all of our test classes and test methods. We then generate our Gradle Test Report and ensure that all of our tests compiled correctly (100.00%).
:::

:::danger
# Problems during Part A:
Since it is our first project, we are bound to face some problems throughout. Although, we didn't necessailry face any problems with the group as everyone was responsive and understood the importance of the project. However, we did encounter other problems.
:::

:::danger
### Problem #1:
The main problem that we encountered was while we were trying to build the project to walk through the code. We kept facing the following error:


We tried to look up multiple solutions online including changing our JDK but nothing seemed to work.

:::success
### Solution #1:
We ended up posting in the class Microsoft Teams Discussion Forum. We saw that other students were encoutering the same problems. The professor replied and said to comment out a line in the build.gradle file. This fixed all of our issues and we were able to sucessfully build the file and walkthrough it.
:::

:::danger
### Problem #2:
I, and some of my other groupmates, initially chose some of the DoubleLinkedList class to perform tests on, however, after the lecture last week (10/05/2022), I had came to learn that it is not okay to use the DoubleLinkedList class to perform the tests on since they were already done.

:::success
### Solution #2:
Upon learning about this, I quickly changed my test classes to the the IntArray class and the DynamicArray class. I also informed the other students in our Teams chat to let them know since some watch the recording later on.
:::

:::danger
# Problems during the Part B:
In terms of the actual testing, I did not encounter many errors. It was pretty straighforward after I worked on the class activity and looked at the code examples. The only difficult part that caused some errors for us was merging our branches together.
:::

:::danger
### Problem #1:
Something I faced as a problem was that once I had finished all of my tests, I realized that I wasn't accounting for some of the branches that could arise. I was simply testing the basic functionality of the method and wasn't accounting for more complex methods with CC's higher than 1.
:::success
### Solution #1:
When I realized this, I began paying closer attention to the class and the methods that I was testing. Doing so allowed me to understand why certain methods had higher CCs and to understand the different possible branches that could arise. This allowed me to fix my code and ensure that I was also testing for possible branching.
:::

:::danger
### Problem #2:
After fixing my tests to account for problem 1, I also faced a problem because the Professor informed me that I wasn't really following best practices. Although my test cases did work, it would be difficult for someone to see exactly where, in their code, they had an error.

:::success
### Solution #2:
When I was informed of this, I looked through the lecture slides again and began to follow them more closely. As a result of this, I began breaking down my larger tests into a number of smaller tests that only checked for one thing (one branch). I also used a nested class to nest these tests together to have a cleaner looking test class.
:::

:::danger
### Problem #3:
Since I was the first to create a pull request and merge into the main branch, I, personally did not encounter any problems with merging. However, as others in my group began finishing up their tests and creating pull requests, we realized that we were going to face merge conflicts since some of us tested the same classes and we wouldn't be able to merge automatically.

:::success
### Solution #3:
We initally solved this by resolving the merge conflicts by combining our test classes into one test class using the append feature in the IntelliJ IDE. We then ensured that each test method was labeled with the tester's name so that even though they were all in the same test class, it could easily be identified who did which method in the class.

However, after speaking with the professor, we realzied we had to change our file structure so we fixed this problem by creating separate packages with each of our names and putting our test cases into our own packages.
:::

:::info
# Project 1 Debrief:
This was definitely a fun experience since it was my first time working on a group project using version controlling. Although it was stressful at times, I still enjoyed the overall experience of collaborating with others to create one big project!



:::