A I AOI

Testing is another one of those things that is essential for software development, yet something I only started using in 3081. This semester I am actually taking two classes where the importance of testing is being stressed, 3081W(Project Design and Development) and 5801(Software Engineering I). The reasons to test are not as obvious as it may seem. The obvious reason might be a programmer testing if his code does what it is supposed to do, but the less obvious reasons are to test that the program does not do what it is not supposed to do, or that it meets "business requirements" (a statement that shows up often in Software Engineering especially). Testing for what is not supposed to happen is harder than testing for expected behavior. One has to test for boundary input, invalid input and weird external things like what will happen if the power goes out and system reboots? Those are just some examples of the reasons to do testing. Being that there are so many reasons to test there are different flavors of testing to try and achieve it all. Some of those include unit tests, component tests, integration, regression, system, black and white box testing. For me to cover all of them would be a fruitless endeavor, as I am relatively new to the concept. The little exposure I do have through 3081W, is unit testing and CxxTest as the tool to do it.

So, in more detail, unit testing is testing of specific functions or specific (small) units of code(where unit can be a method or a single class). When unit testing the programmer doesn't just check if the code fulfills a business requirement but also if given inputs the code behaves exactly as expected. Now, this goes for both "good" and "bad" inputs, as it is a good idea to write tests that check expectant failure behavior. This particular area however, is where challenges might arise. As with all tests it is the programmers job to come up with the ranges of "good" and "bad" inputs. That being said, once the unit tests are written they can be augmented with new tests as as the project grows in complexity. This allows a systematic and paced way for the programmer to come up with a good range of possible inputs for the unit tests instead of doing it all at once in a more general test at the end once the large project is over. This incremental approach that unit tests afford really help the programmer in satisfying one of the major requirements of every test -- thoroughness. Another important feature that every test in programming needs to strive for and unit tests can provide is independence. Things like mock objects and fake inputs not only allow to test almost the whole gamut of inputs, but also allow to isolate each and any part of the code to ensure that it works correct.

As with every good idea, someone takes it and makes it better. The way that happened to unit tests is the invention of the many widely available testing frameworks. A testing framework adds more than just the convenience of filling in a few lines of repeated code -- not that insignificant feat in itself as boring "repeatable" parts of coding can often be the cause of programmer error(and thus result in false test results). Testing frameworks also allow the tests to be automated, professional and repeatable --- another 3 important hallmarks of a good test. These three hallmarks I think are especially important in a group project type setting as instead of writing your own tests in one's own unique and quirky way of writing code the testing framework allows for a standardized way for the programmer to write tests. Moreover, having the tests in the framework speeds up the understanding of another programmer who is later trying to augment or simply to understand the tests. Moreover, the framework setting also eases automation allowing someone who knows nothing of the content of the tests to still be able to run them.

The only framework I am familiar with is CxxTest and it pretty much provides all the benefits above. Something that I found a little unsettling at first is using code I don't completely understand. To create tests it is only necessary to include the file that is being tested and use CxxTest's function calls in a CxxTest header file to create the tests, the framework will generate the cpp behind the scenes. As someone who is used to understanding all the in's and out's of what I am turning in this was little unsettling. Another personally challenging thing I found is coming up with good mock input, but once done the set up of TS_ASSERT_EQUALS doesn't require much more thought to implement.

After using CxxTest I think of testing frameworks in context of backing cookies. Backing cookies is good but difficult, so testing frameworks are a form of a ready-bake variety -- you just add some ingredients and you can pop them in the oven!

Iteration 1 deadline has passed and the fruit of mine and my partner's labours is on the chopping block (also known as the subversion repository) for the TAs. Now for my second assignment I need to describe some of the challenges encountered when working in a pair environment and how we addressed them, as well as discuss what we’ll try to do different next time. One of the major challenges that I encountered when working with a partner was the issue of time constraints, and another challenge is work styles.

“Deadline" is quite a relative concept, and thus the challenge. Yes, the absolute deadline exists, but in reality we both have our own separate commitments. Thus, while we might have x number of days to work on the assignment actual availability depends on our individuals schedules as well. To address this conflict we tried to sync our available times, but maybe next iteration we should plan out our availability to work together when we have a better idea of how much time the project might take. If this is not done than too much work might be left until the last few days.

The second challenge that I encountered is the difference in work styles. I am quite comfortable at holding the monitor in an unblinking stare for hours on end. My partner on the other hand has a different approach, one where she works a few hours at a time taking breaks in between. This conflict I think is easier to address. Now that I know my partners preferences I’ll plan accordingly and try to finish the easier parts by myself and leave the complicated things that will need two heads to figure out to our group sessions.

Basically, working together is great as long as both partners clearly communicate the amount of time available and expected time commitments for each session. These types of conflicts will take some adjustment to solve as issues relating to time management and work styles extend beyond this class or this project. Moreover, adjusting one self to someone else is always difficult, but there are always upsides. Being flexible is just as important as being good at programming, as working alone I won’t be able to complete complicated large projects on time no matter how good I am.