CSCI 3081

Unit testing is testing a part of code separately from the main code in order to see if it is properly working. This process allows programmers to test each function on its own to find and correct any errors present thus removing errors before code is complete making it easier to resolve the main code. When one tests by unit testing it lengthens the time to complete each part of the code and one will have to address issues when bringing the code together for whatever reason, but it simpler to see errors within the code as there due to less to filter through. Unit testing does not address every issue because it is like building stairs, you build one step at a time making sure the step is properly made but once finished building you have to add paint or carpet to be complete. In other words, you complete each function of the code (stair) with unit testing but not the code as a whole (staircase) meaning that the code has trouble with using multiple functions interchangeably. These are, in my eyes, a great tradeoff to testing code at the end and having to spend a long time correcting small pieces of code or even rewriting big portions of it to get the main program running properly.

CxxTest is a program used by the 3081W class to do unit testing on code with the functions TS_ASSERT and TS_ASSERT_EQUALS. CxxTest was used as a library to store functions that could be used to run a program with specified input and compare those results with an expected output. The result would print how many tests were run and, if succeeded, would print OK, otherwise it would show the errors in terminal. One of the functions was TS_ASSERT which runs a function or a statement like 2+2==4 to see if true and if so this test is considered to be passed. Another TS_ASSERT_EQUALS which takes in two parameters, a function like 1+1 and an expected result from that function like 2, to see if they match and if so TS_ASSERT_EQUALS passes that test.We tested the program readInput by first creating a readInput test file and its header file, and a makefile in order to test different inputs and compare readInput's results with what was expected. The makefile was created in order to compile the code and access the cxxtest library to get the proper functions available. CxxTest created code in the readInput_test.cpp file in parallel to how many test cases were created.The results worked, shown by it saying OK for completing all the tests in the readInput_tests' file.

Unit testing with cxxTest allowed us to see if our code worked, not just readInput. This was great because it allowed us to find small errors that we could resolve before putting it into the main code eliminating excessive and confusing testing when testing the preliminary main code. This kept us at a smooth speed with our code creation because there weren't multiple errors and we could test with big files and only found small errors present that were easily fixed. There are some code that makes it hard to unit test with cxxTest because it could have special input parameters, no parameters at all, requires global variables, requires use of user created functions, and so on. A way to get around this is to test the functions that are used by desired function that can be tested, place the global variables in the test function area, and create simple versions of the other related functions that can't be tested alone with one possible setting to test the desired function.

Source control and subversion are helpful tools for group code work. Source control, I believe, functions on the idea that the source code is stored in a server while the partners involved modify local versions and changing the server's to reflect said changes. This is done to allow multiple to work on the same code over long distances and assisting each other on the code when needed. Subversion, also called svn, functions as a program that optimizes source control and is what we used in 3081W. Svn has a repository, both for individual and group, that allows us to store are code online for others to see. When we add or modify, with the command add and commit respectively, the existing code on the repository we can leave comments telling what we did and why. We can update our local code version with the repository code with the svn update command if said code is different from local. These features allow easier long distance group code work because our partners can understand what we did and retrieve the alterations for their own use.

However, there are drawbacks such as remembering to delete data from the repository and not your own local server. Some issues caused are an inability to remove it from the repository without administrative assistance, loss of doing additions to repository in the file that contained the deleted file, or an inability to change the repository at all depending on where you deleted the file locally. All this can be resolved though with the help of an administrator or someone similar. You can also force some of the commands or use the resolve command to fix some issues but these won't fix everything. You have to work around svn server related issues such as the site being down, which can be circumvented by using email to transfer altered code, although emails can only hold so much information and don't allow quick changes to occur.

Some of the drawbacks of working with a partner is that you become dependent on each other. This can be troublesome as both can be working on code that the other needs. A way to solve this would be to do small pieces at a time so that one partner doesn't have to wait for a long time for the other partner to finish. Trying to get time to work with each other in school when both have conflicting responsibilities becomes difficult. However, thanks to the Internet one can communicate from anywhere there is a computer allowing both partners easier communication options.  It becomes easy to slack off and let the other partner do all the work. Planning for this and working on a set schedule that has each partner working on their own pieces allows for less chance to slack off. Without good and proper communication the projects become like working on them individually, leading to issues like conflicting code or ideas. Yet again, if the partners communicate over the Internet this becomes a minute issue.

Some of the benefits are that you can get a fresh source of ideas and can ask questions to the other in case you don't know something. This can lead to solving problems easier than when working alone so long that each partner is actively communicating with one another. It also allows project flow to increase and smooth out. The work is split between the two making the project easier to do due to only needing to write half of the code to complete the assignment. Planning beforehand what each person is supposed to do allows this ease to continue so long as it is not abused or misinterpreted. You aren't as stressed because you have someone to rely on besides the TA's or the teacher leading to calmer thinking and easier working conditions. Yet again, it requires communication between the two partners to be effective or else you have no one to rely on because you can't communicate with them.Being able to talk with another person allows one to become more knowledgeable about the class as you can talk to your partner and meet new people through them that you can be friends with or help you work. This requires effort on one's own part to become successful in both making new friends and learning new things.

I am good at writing comments for code. I try to make sure every piece of the code
is properly explained. I do this because when I first started programming I hardly
commented, if at all. When I came back to my code I had to constantly study my
code to understand where I was on my process. I would program a lottery program
and not comment on any part of it and when I made a mistake I had to go through
the entire program to figure out what I did wrong. The same happened when I was
doing a math test program. It honestly was horrible and I could not stand it at all.
Due to the hassle of this procedure I started writing comments in my code building
up over time until I comment nearly all my code. Now I revise my comments in
order to make them more understandable. In a recent battleship program I
commented on every line of code to state what it does and how it relates to other
parts of the program. Now, due to my experience, I have become a competent
commenter that details every step of the process. Another program aspect I am
good at is looping. I have had a lot of practice and study of it in 2021, 1901, and
1902. Initially though I performed unnecessary procedures involving loops that
slowed down my code considerably. But, from the classes I have taken they taught
me what should be contained within loop conditions so calculations that need to be
done once aren't done repeatedly and all parts that can be done in the loop are
done within the loop.
I really don't know defensive programming that well. It sounds good because
keeping the program safe from errors or damage is something every program
should have. I have no idea how to properly do this though so I would like to be
taught it in class or from the teacher directly so I can create good and safe
programs. I am not good at creating a useful class hierarchy because I tend to just
jump into coding without thinking about the steps beforehand. I have little
experience calls functions outside the current class and I really am not comfortable
calling procedures from outside my current code. I would have to ask classmates,
Tas, or the teacher about how to do this efficiently, but I would like to be taught how
to do this properly in order to keep my program looking easy to understand by
branching it into different classes and making it more manageable by being able to
debug one class at a time instead of all at once.