Blog 4 Testing

By lorxx033 on November 10, 2011 1:57 AM | 3 Comments | No TrackBacks
    So far this semester, my partner and I haven't really wrote any unit tests for our project. Besides writing tests in the lab exercises, I have never used cxxTest. I understand the importance of unit testing, but when we write our code we try to make sure it outputs the same data as the sample output given to us and we don't do this until we finish writing almost all the functions.
    cxxTest is a testing framework for c++. I don't know how if there was some installation behind the scenes before we started using cxxTest, but when we first used it we extracted cxxTest in a specific directory structure within our group repository. After that, cxxTest just worked. It was quite fun writing small tests and seeing it run in lab. It's the only testing framework that I know of for c++ and for our purposes, I believe it's sufficient. I don't write a lot of test cases and I don't know how to write more advanced testing techniques.
    Writing code and testing each function before moving on to the next is helpful and ensures that you can be confident in your code working and this is what unit testing is for. This practice can save a lot of time in the long run. When we were programming for iterations 1 and 2, we didn't run our program until we thought we were finished. Only then, did we compare our program's output to the expected output, but before we could even do that we ran into a lot of errors that we were unsure of. We spent hours trying to figure out what was wrong. Was it our regular expressions? Or was it something we missed in our consumeWhiteSpace function? Maybe we didn't correctly output the data in our printout method? This would not have been so hard to debug if we would have wrote unit tests. It would have helped us to eliminate many factors and pin pointed us to a more exact cause of the error.
    Ideally, writing unit tests through cxxTest is a very good way to program big projects, but my partner and I just don't do it. Perhaps it is just a bad habit of mine not to write small tests to make sure all the underlying methods work before I move on to the next method. Since unit testing is used for testing small parts of the whole program I don't think a lot of time will or should be spent on it. As it focuses on a small portion of the overall code it may still miss some unforeseen errors.

Blog 3 Subversion and Source Control

By lorxx033 on November 3, 2011 11:14 AM | 3 Comments | No TrackBacks
    Source control is a way for software developers to maintain and manage code. It is a very useful tool when working on a large project with a group of people. Using source control allows team members to work on the same code files from different locations and times and keeps all files in sync. Another very useful feature of source control is the ability to roll back or revert to an earlier version. We've run into situations before in lab where we messed up a file tinkering around with our makefile. It changed all our code in a file into jibberish. But luckily for us, we were able to revert that file to a previous version via svn revert ourFile.
    For our WTF Project we have been using svn as our revisioning control system. It is terminal based and, for our purposes, simple and powerful enough. Using svn allows us to work on a local directory and upload it to a repository when we commit it. Uploading it to a repository means that any team members assigned to the repository can get the latest version to their local directory by updating. This means that any team member can work on the files from anywhere, at anytime and commit the changes to the repository so that other team members can update their local directory from anywhere and anytime. Of course this committing and updating requires good communication across the team otherwise there will be conflicts when committing and updating.
    When all team members are able to communicate effectively, running into conflicts will almost never occur. So most of the time, using svn to commit and update is very easy. But when there are conflicts, perhaps using a source control with a gui would be easier. In svn when you run into conflicts, it can be quite hard to figure it out. Sometimes it is just a simple merge of code and reviewing it and then resolving the conflict. And sometimes it has to do with hidden svn files and directory structures that can cause a lot of confusion and trouble. But when it comes to a situation like that and I can't seem to solve it, I just backup the files I've changed to a different directory and delete the whole local directory and check it out. After the checkout, I just copy the code from the backups to the local files and commit.
    So for anyone planning to use svn, the main commands you need to know are: checkout, update and commit. Everything else can be Google'd when it arises. Use checkout for a fresh local directory copy of the repository. Use update if you already have a local directory to get the latest version from the repository if any, I always use this before I start coding away. And finally use commit when you've made changes to files, so that it uploads the changes to the repository. Also don't forget to use the -m for committing files, it allows the person committing the changes to comment what he/she is updating/changing. This is very useful when the group is planning to go back to a certain revision number.

Blog 2 Working in Groups

By lorxx033 on October 15, 2011 7:01 PM | 5 Comments | No TrackBacks

I remember having to buy a new laptop Monday morning at school because I had left my original laptop in a mess over the weekend. After opening and installing the required programs to SSH into the IT labs computers, I was finally able to look over the code my partner had already started. It took me 3 to 4 hours to read through the code and understand what was going on.

The concept behind our current code seemed like it would work, but for some reason it just wouldn't give the expected output. I would pass the program a file and it would return what looked like a cat command in unix. I thought this had to do with our regular expressions we wrote, so I went through them all to see if they were correct. I even thought maybe our ordering was wrong and tried that too, but none of what I tried was working. Since I wasn't confident in the changes I made, I did not commit any changes and waited until I could talk face to face with my partner. When my partner and I were finally able to meet up and tackle the program together, we were able to fix all of this.

When there are a set of two eyes to look at the code, you're able to pick up mistakes and double check code a lot faster. My partner is quite the programmer, but like me, sometimes mistypes code. Together we can see what each other is doing and prevent little mistakes like spelling from entering into the big pool of debugging what has gone wrong. Or while writing code, he'll suggest another method or way of writing the same function that may be more readable or faster.

After strenuous hours of programming, we finally figured out that it wasn't our regular expressions that were wrong. It was because we had forgotten a very simple, but important character "^" in some of our expressions towards the end. And we also realized that we were printing out the name of every terminal because we stored everything in our code. Instead of changing this, we decided to just alter the print method to only print certain names of terminals.

Working together is overall better than working as an individual. I believe the pros outweigh the cons. When working together we're able to make a decision right on the spot, but when working individually there are some changes to the code that we may not want to make. Programming together is a lot faster than by oneself too, especially when you run into unexpected errors.

Blog 1

By lorxx033 on September 27, 2011 10:56 AM | 12 Comments | No TrackBacks

Topics I'm pretty good in ...

Given that I know what I'm doing when I start programming, writing loops and semi-defensive code isn't too hard, but it does take me awhile to get to that point. I'm a little slow to start when given some sort of programming objective, but once I sit down to think and figure out what it is that I need to do to reach that objective it's not too bad. I suppose a key to defensive programming is how much you actually know about the code and objects you're working with.

Version control doesn't seem too complicated so far. I suppose as long as there are no huge conflicts that arise, using it will be a breeze. The idea of having a time-capsule like environment seems very helpful for working on a project in a group. I can see the various scenarios where version control will come in handy, such as me messing up an almost complete project. Having the option to roll-back will be very nifty.


Topics I'm not too confident in ...

I've always had trouble writing. It would be nice to pick up a few more writing tricks or methods of writing. Most of my papers that I've done for my courses here at the U have always come up a page short of the requirements. My problem is that I tend to keep things short, I can't seem to work an idea through 5 or so pages. So my papers are relatively weak because I cannot carry an idea.

Another struggle for me would be designing. When given a small programming assignment I'm able to come up with the general methods I would need to achieve the program, but I often find myself making a lot more methods and global variables as I continue programming. Sometimes it feels like I'm not getting anywhere unless I have some code written and that really gets to me. Designing and planning takes time, but I feel that sometimes I spend too much time thinking about what is needed.

Archives

Search

Recent Comments

  • covey025: I think that the fact that you don't use CxxTest read more
  • zhan1162: I think you and your partner is doing well in read more
  • norhe003: In my opinion, one of the better reasons to use read more
  • nunxx001: Come to think of it, source control with a GUI read more
  • geexx041: You pointed out some really good points. From my experience, read more
  • khanx107: You have some very good arguments here about the benefits read more
  • tranx328: I agree that working together definitely is a good thing. read more
  • hwang142: I agree that working together makes it easier and faster read more
  • barri084: How has SSH been working for you? I had some read more
  • jonat003: Yes, I am totally agree with you. Working in groups read more

Recent Entries

Tag Cloud

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