Group Communication and Set Up

My group’s main method of communication was through Microsoft Teams in the private group chat since that’s what we were already using for the class.

In the first meeting, we had some difficulty setting up the wiki page since most of the members weren’t well-versed in using GitHub. So, we were learning how to navigate the pages together while one of the group members shared their screen. We chose a team leader and set up the basic outline of the wiki page. This first meeting was mostly about introducing ourselves and getting to know each other which I thought really helped us open up to one another.

In our second meeting the day after the first one, we completed a lot of the tasks required for Part A of Project One. We assigned roles to every member so the work could be distributed evenly. Our team leader made a poll on Doodle.com so we could figure out a weekly schedule for meetings that worked for our group. This was essential to helping us easily find out the days for us to regularly meet (Mondays and Fridays at 6 p.m.).

In our third group meeting, my group and I met two days after Project 1: Part B was assigned to us. We mainly discussed writing the unit tests and what was to be completed by the next meeting which was a couple of days later. During the meeting, I shared my screen to show the rest of the members how to make a new unit testing file since a couple of people were confused about how to do that. It turned out to be helpful for the others since they were new to writing unit tests.

Plans, Schedules, and Tasks

Some of the group members have busy schedules so we agreed as a group that not every single group meeting is required. All we ask for the members to go to as many as possible. I came up with the idea of making a comment in the group chat after each meeting consisting of things we talked about, what tasks are to be completed, etc. This way, if a member were to miss a meeting, all they would have to do is check the chat to keep up to date with everything. This also helps our group keep a log of all our meeting dates as well as the contents of our discussions. Thus, I took on the role of the meeting note-taker. After each meeting, I post a chat consisting of a bullet-pointed list of everything we discussed and did during the meeting. At the end of the list is a point named “Upcoming tasks”, so every group member knows what is to be completed or worked on by the next meeting or project due date.

In the third meeting, our group decided it would be a good idea to create a project board on GitHub to keep track of all our progress. One of our members volunteered to create it so we could easily view the progress of the whole group. This was an excellent way for the group to keep organized and ensure that everyone finished all their unit tests in time for the deadline.

Our semi-weekly group meeting became extremely crucial to the success of our project. It allowed for proper communication among the entire group as well as getting everybody onto the same page. We could also freely discuss any concerns we had regarding the project.

Development Issues

As mentioned earlier, I had never used IntelliJ or written unit tests before the project, so it took me a while to get a grasp of everything. Once I finally did, writing the 3 unit tests for methods with basic complexity and 1 with intermediate complexity wasn’t too difficult. However, once I got to the advanced methods, I had a lot of trouble trying to figure out ways to correctly test the edge cases. I chose PrimeFactorization for my advanced complexity requirement which has a CC of 6.

The first test I wrote was for n is less than or equal to zero. I didn’t know how to write a test that would expect an error when running the program with an input of n<=0. I had to do some extra research and found that I needed to use “assertThrows”. I found a chart consisting of many Junit test commands and that ended up being extremely useful in this project. Without the chart, I wouldn’t have known about assertThrows. Then I played around with this until I finally got it to work. The next section details one of the hardest parts of this entire project for me.

Another possible path was n is equal to one. The number one is a special case since it’s neither prime nor composite so an empty list is supposed to be returned. I tried almost every possible configuration to show that the ArrayList is empty in the expected spot, “[]” being just one of them. I did some reading up on useful methods of testing on ArrayLists and tested many of the ones I saw. Finally, after trial and error using .isEmpty() and .size()==0 allows me to test that the array is empty without having to explicitly write out an empty list such as “[]”.

Writing a unit test for n being prime was straightforward since it just returns n by itself in a list. I had a bit of difficulty with n in positive since it wouldn’t allow me to directly create a list so I just used .add(num) to add the numbers to a new list then put the list name into the expected parameter for assertEquals. After this, it was still giving me errors for some reason, so I did some reading about ArrayLists taking a “Long” integer. I found that I had to add an “L” to the end of every number to indicate it was a Long integer instead of just a regular integer. This solution resolved all the errors present.

This next case was almost just as hard as if not harder than the unit test for n=1. Another case I thought of is when n is extremely large. I knew I couldn’t keep using is .add(num) method for this test because it would take too long to add every number one by one especially if I wanted to test multiple different large numbers. So once again, I had to do extra research and read articles about how to initialize an ArrayList with numbers already inside. Once I figured that out, I first tested on a 5-digit number and it passed multiple times. Then I gradually increased how big n was for each test. When I tested on a 6-digit and 8-digit number, I realized the output was doing something strange. Running the program with a small number returns a list was all the numbers in ascending order. But with extremely large numbers, sometimes the list returns with the numbers out of order. I was using assertEquals and the tests would sometimes pass and sometimes fail depending on if the number in the list returned in the same exact order as the expected list I created. Even though the contents were the same, the tests were still failing. I read a couple of articles about testing to make sure the contents of two lists were the same and disregarding order. I found that I had to use assertThat along with a method like containsExactlyElements and a pop-up message on IntelliJ asked if I meant “.containsExactlyElementsIn()” so I used that method. This just checks if the numbers in the expected and actual array are the same instead of if they’re in the same order. I decided to use RepeatedTest(5) on this particular method to ensure it properly works. Finally, everything worked successfully. I went back and redid the previous tests with this method too on the off chance that the order is off for the smaller numbers.

Tools I used in my development

The main tool that helped me in this project was a chart consisting of all the Junit testing methods. I had never written a single unit test before this project so seeing all the useful methods for testing was crucial to the success of my project. I even shared a link to the chart with my group members to help them if they ever became stuck. I also used the in-class Calculator Activity I did as a guideline for how the structure of my unit tests should look. It took me a couple of hours to learn how to use IntelliJ and write unit tests since I’m also new to everything, so I was glad I saved the rest of the members from having to struggle as I did by showing them a step-by-step tutorial during a meeting. I was originally nervous about writing unit tests since I had never written any before. However, after slowly going through the Calculator Unit Test Activity in class, I felt much more confident about my ability to complete the project. Even though it took me a couple of hours to figure out how to do everything on my own, I really took my time by slowly watching the lecture and completing the activity. In the end, it paid off because I learned a lot and it allowed me to aid the rest of my group in this project. Finalization of my unit tests

After spending many long hard days working on my unit tests, I finally finished and tested it numerous times to ensure it was safe to finally push to the main repository. In one of my commits, the .idea/ somehow ended up being added to the commit even though I only added my .java file. So, when I tried to do git revert to undo it, it wouldn’t allow me to and while I attempted to fix everything, I somehow made it worse. After 4 plus hours of attempting to fix the mess I had made, I decided it would be best to ask my professor for help on what to do next, so I didn’t make anything worse. My professor sent me a long list of options I had to fix my branch being both behind and ahead of the main branch at the same time. After attempting one of the options, I was able to resolve the issue and created a pull request during a group meeting which successfully merged into the main branch. I was extremely grateful they took the time to help me when I was lost regarding what to do next.

My group leader ran my unit tests and some others that were already merged during the meeting. The Gradle report showed that all the passed with a 100% so my portion of the project was accomplished. Overall, this project was incredibly difficult for me due to my inexperience with IntelliJ and writing unit tests. However, working on the project early gave me an ample amount of time to work through the unit tests and learn how to write them. Taking the time to thoroughly learn unit tests in this project will prove to become useful later in my coding career whether it's immediate or in the future.