Blog 4: Testing


We are here one more time for another edition of our 3081: Program Design and Development writing assignment, this time getting into the topic called: Testing.

Testing? ...what do I mean by testing in terms of computer science? Well, testing is all about producing failures in our own code just to be sure that it is doing what it is supposed to do. Testing is the most effective technique to building up confidence that small pieces of code work as expected. As developers, we spend time debugging, printing variable's values through the code, verifying that those values are the ones we expected to be. However, we also know that it is not enough for testing purposes, so the next question is: How to test a method, a function, a class, a whole project? I found the answer in Regression Testing which states that for any failed execution must yield a test case and it remains as part of the project's testing unit ("Seven principles of software testing", 2008).

There are two kinds of test cases: manual and automatic. Automatic tests are derived from the specifications of the project and Manual tests are not intentionally intended as a test run which is the case for the tests from Lab 5. Recalling from Lab 5, there are three tests in readInput method. The first test was set up to not provide any file name by changing the first argument from 2 to 1 in order to prove the correctness of this test. For the second test, we provide a non-existing file to function makeArgs (const char *a0, const char *a1) which returns an expected null pointer. The last test just confirmed that when given a proper existing file name the pointer returned is not null. Manual tests like those previously mentioned are good for understanding of the method's functionality and its arguments.

Based on the premise: of finding all bugs in our code, no just one. We should consider an empirical assessment strategy called random testing. Random testing states that successive bugs might be of different nature; hence, we should try as many tests as our creativity and knowledge allow us to do it to uncover as many failures as possible as a function of time. In other words, we should not underestimate a seemingly dump testing strategy before we try it.

Testing is far easier in the long run if we put in practice the "pay-as-you-go" model. It means to write a simple test for each small routine as we go along with the project, to spend in a consistent manner some time at the end of the day testing our code rather than having to rush at the last minute fixing too many bugs and reworking many lines of code. In conclusion, testing is not a waste of time and it should not be something that happens toward the end of a project.

Blog 3: Subversion and Source Control


This blog is all about source control and Subversion and before I approach them in its whole context I consider it necessary to define some key concepts like repository, workspace, and mainline. By now it is a common practice to add, update and commit our source directory and source files without too much concern of where all these changes are actually happening. The magic lays in something called repository. A repository is all the project files (both old and new versions) stored in a reliable and safe computer which acts as a server. Okay, but how do my partner and I get access to those project files in order to distribute the project's workload between us? In that case we have another place called workspace. The workspace is a local copy of utilities and code that we need from the repository to work on our part of the project. In order to retrieve copies of those files out of the repository into our workspace, we use the command checkout. The command checkout brings to my mind a situation where I could not understand why the file "translator.cpp" was being skipped when I was updating the /src directory. The textual message was like this: "skipped translator.cpp". As you know, it is not possible to run any test without that file. So, I erased all the files, I update the whole /src directory, and I got the same result over and over. Finally, I asked the TA Shi Bai for advice on this issue who suggested that I should check out my workplace one more time just to see if it fixed my problem. He was right about it, if you pay close attention to the purpose of checking out, you will realize that this command populates your workspace with up-to-date copies of the files you request. Mainline is an useful concept in terms of visual perception, you can image a horizontal line that divides in many branches and each branch is running the same project in different scenarios or stages that later will merge in only one improved project.

Now that all of us have a clear understanding of the three key concepts: repository, workspace, and mainline, I will be able to describe some version control commands that I believe all of us have used very often in the lab assignments. Okay, let me list them: add, update, commit, status, diff, log, and resolved.
svn add: I use it every time I add a new directory, e.g., lab1, lab2, etc. or a new file, e.g., scanner.cpp, parser.cpp, etc.
svn update: I use it every time I want to check my partner's changes in the project files.
svn commit: I use it every time I want to save my changes back to the repository.
svn status: I use it every time I want to see if one of the files has been modified. I remember one time I used status for "translator.cpp" and I got a message stating that the file was not under version control.
svn diff -rHEAD: It is very useful to be sure that you agree with changes in your local copy file versus the current version in the repository before you update it.
svn log: I use it to look at the history to see who committed the last changes in a file in case a conflict arises from output between my partner and I.
svn resolved: I use this command to tell Subversion that the conflict of output has been resolved.

Subversion belongs to the second form of conflict resolution called optimistic locking. Optimistic locking allows every developer to edit any checked out file. However, if you want to check in any changes in a file you will have to update first your local copy to include the latest repository changes before checking in. Then, the version control system attempts to merge the repository changes with your changes. A conflict arises when two developers edit the same line of code. In this case both developers have to decide whose change should be included in the repository. In reality, developers rarely work in the same file in the same line of code. I remember from Lab 3 part of the assignment was to create a conflict where my partner and I were modifying the same line of code. At the end, we resolved the conflict using the command svn resolved.

As you can tell, Subversion is a powerful version control system which allows developers to feel free to change code, update code, erase code at anytime, anywhere without worries. However, according to Andy Hunt and Dave Thomas, close to 40 percent of project teams in the US don't use any form of version control at all ("Three Legs, No Wobble", 2004).

Blog 2: Working in Groups


Have you ever been in a situation where you feel frustrated, especially if you did not cause that stressful situation? Well, what I am trying to say is that I did not have a partner to work with for the first iteration of the class project and it wasn't until last Thursday that I finally met my official partner. Let me explain to you the story behind that issue.
Everything started from the day that we needed to work with a partner on the lab 3: Subversion and Iteration 1. Until then I had been working on my own. You know how it goes... you work on the lab assignment, you make some progress, you take a break, and so on. Nobody depends on your part of the assignment to be done, the deadline is coming and you are aware of that, but you know that you can make it. One day I was assigned a partner to work with from the TA. Okay, no big deal, but guess what... Yea, they assigned to me somebody who dropped the class on the first day. Heh, heh, heh. I know you think that is funny. Well, yeah, it is funny, I laugh too. I found out when I called my partner and he told me that he dropped the class after the first day. After I talked to the professor about it, he figured out how to fix it and, as a happy ending, I got an actual partner to work with. The purpose of sharing this unusual situation is to express myself in terms of how difficult it was for me to start working with some else as partners. You might ask where the difficulty is, I don't see it? First, we were running out of time, so they give us a fair amount of extra time to get the lab done. Second, I forgot to tell you that before this I tried to do lab 3 on my own. However, you will agree with me that it does not make sense to do it without a partner. Hence, it was a philosophical experience to deal with.
On the other side of the coin, I have been learning a lot about myself working with someone else. I did not know that I could be friendly with someone else besides me. Oh no, don't take it seriously, I was just kidding. Okay no more jokes about it, back to business... I was saying that actually this idea of having a partner turned out to be good for me, my partner has a lot of experience as a programmer so it is an opportunity for me to learn from somebody with such expertise. It helps a lot when I am stocked with a function in the code. Last time I remember that I quite did not understand very well some part of the code from iteration 1, so he spent some time explaining iteration 1 to me. It seems that he already knows how to program in C++ very well.
I am learning C++ and it is kind of a new language for me, I have used C or Java until now, it is just a little bit different... new keywords, new headers, more functionalities... You know, something like that. Before I used to use the header file -- together with the function -printf ()- in order to output data to the screen. Now, I use the header file --with the standard output stream object -std::cout- just to cite one example. The Subversion control system is completely new for me. It gives us a controlled access to storage documents and code. I would not image myself working for a company without having a basic knowledge of how to use version control systems. Since I became more familiar with Subversion commands, I can appreciate the full meaning of svn commit, svn add, svn update among other commands. It may sounds silly and trivial for many of my classmates, but for me is new knowledge. It is fun to have your own workspace to mess around whit the sample files and also be able to play safe with the assignments knowing that you are allowed to do it. Thanks to the repository, is possible to manage conflicts between users accessing at the same line of code, keep track of old versions, update files, etc. and all of these in only one single software tool.
In conclusion, it has been an intensive curve of learning for me since the beginning. It is always exciting to learn a new programming language like C++, I find very interesting and time consuming to use it. Definitely, I look forward for new challenges, new assignments, and willing to learn more than we are expected to learn. By the way, I am also re-enforcing my English writing skills.

Blog 1: Writing assignment


I am looking through the different software techniques in the syllabus and the one about general code easy to understand seems to catch my interest. I believe that we as programmers is imperative to write code as easy to read as we can. I think that is very unprofessional to write a program which is a mess in terms of clearness. I expect that at the end of this class I will be more capable of using the software design specifications; although, I am not quite sure what it means by that. Another technique that sounds interesting to learn is the one about developing a set of routines. Anyway, I am taking this class because I am willing to learn as much as I can.
On the other hand, I think I feel more confident using integrated development environments and UML. I was programming little bit in Java and one of the assignments involved to create UML diagrams. Besides that, I was using the IDE for C++ that comes with Visual Studio, but now I am dealing with Linux. It is always fun to learn new software platforms. I am far from being a computer science guru, but I believe that this course is full of new challenges, knowledge and projects that will lead me into a new level in the computer science world.

Recent Comments

  • steph034: You may want to slightly change your definition of testing. read more
  • norhe003: I don't know if it's possible to be "finding all read more
  • ranki040: Very good work. I like how you really laid out read more
  • ahlqu038: Nice touch, referencing the paper. Caleb Ahlquist read more
  • jinxx241: svn add, update are used usually once when we work read more
  • sherm190: While its true that developers are rarely working on the read more
  • edwar583: I'm new to using C++ also and I understand how read more
  • mandy014: Props to you for getting through the first couple of read more
  • jinxx241: My situation was a little bit different, but I read more
  • jinxx241: My situation was a little bit different, but I read more

Find recent content on the main index or look in the archives to find all content.