So, in retrospect, I did not pick a very good title for my last post, being that this post is actually on testing. This topic also can not be tied into the theme of my previous blog posts, so I'm just going to dive in here.
Unit testing is the process of performing tests on smaller pieces of code as to make sure they will work as desired when the whole program is finished. It does this by creating a testing environment to check whether the "units" of code work how we think they should. So, for instance, say we were making a program to do some mathematical computations using words instead of the symbols (e.g. 3 plus 2 minus 5, as opposed to 3 + 2 - 5) and we didn't have times or divided-by done yet, but we did have plus and minus done. We want to check whether plus and minus are actually doing addition and subtraction, so we use our testing environment to check if this works.
Unit testing has been an extremely useful tool to us so far, in that it saved us quite a bit of time, in the long run. We didn't have the part of the scanner that was creating the linked-lists of tokens working quite right (it was putting a null node for all the white space), and the way we figured out that this behavior was occurring was because of the tests we ran. When we were printing the tokens out to a file, everything looked OK, because when it tried to print the null node, nothing happened, so it just went on to the next one, so we assumed everything was working as expected. When we ran the tests, however, we found out what it was actually doing, and then were able to fix the problem (incorrect reg-ex for white space).
I think unit testing is a good thing to use in any software development project. If you write all the code, and save testing until the end, chances are that you are going to have a crazy amount of errors, and fixing these errors is a pretty daunting task. With unit tests, these errors become more manageable in that you only have the one error to fix at a time. It also makes for a much smoother development process because you know the parts that you've finished will actually work as you planned them to, so if you have later pieces of code depending on a piece of code you've written at the beginning of the project, you know what you've written is reliable.
I really don't have anything bad to say about unit testing. It's a good tool, and it should be used. I'm pretty hard pressed to find an example where you wouldn't want to make sure that your code is working properly, and that's exactly what unit testing does.
Wednesday, November 9, 2011
Tuesday, November 1, 2011
The Test
The siren song, that is svn, has been tantalizing me for the duration of this class. It seems like it'd be great, but then it steers my programming ship directly into a cluster of rocks. Needless to say, my relationship with svn isn't the best, but I think it's just the context in which I'm using it that makes me want to avoid it.
For those that don't know, svn is short for subversion, and it what is called a version control system. What this does is let many people work on the same project from different computers, potentially at the same time. When you get done with what you're working on, all you have to do is commit the changes you've made, or files you've added, and then everyone else can update the version they have and see and/or edit what you committed. In theory, this sounds great, but what happens when two people are working on the same file and both try to commit it? This is only the first of a few problems that I've encountered with it. More examples will follow.
As I said earlier, svn is tantalizing. What i mean by this is that it sounds great on paper, and maybe it is great if everyone working on a project that is using it fully understands it, but in practice, for me, it hasn't worked all that well. I concede that I might just think it's stupid because I have done almost all the work on the project in the presence of my partner, and thus have never actually needed to use it. It could also be that I am not the most adept svn user and thus do not understand why I get errors like this:
svn: Commit failed (details follow):
For those that don't know, svn is short for subversion, and it what is called a version control system. What this does is let many people work on the same project from different computers, potentially at the same time. When you get done with what you're working on, all you have to do is commit the changes you've made, or files you've added, and then everyone else can update the version they have and see and/or edit what you committed. In theory, this sounds great, but what happens when two people are working on the same file and both try to commit it? This is only the first of a few problems that I've encountered with it. More examples will follow.
As I said earlier, svn is tantalizing. What i mean by this is that it sounds great on paper, and maybe it is great if everyone working on a project that is using it fully understands it, but in practice, for me, it hasn't worked all that well. I concede that I might just think it's stupid because I have done almost all the work on the project in the presence of my partner, and thus have never actually needed to use it. It could also be that I am not the most adept svn user and thus do not understand why I get errors like this:
svn: Commit failed (details follow):
svn: Server sent unexpected return value (405 Method Not Allowed) in response to MKCOL request for '/svn/F11C3081-40/!svn/wrk/
I still don't completely know what that one was telling me.
There is also the problem of conflict resolution. For those who haven't used svn, when more than one person tries to make changes to the same file, you get, what svn calls, a conflict. This can be resolved by merging the two files(although this is something that has to be done manually, as svn does not give you the option when a conflict arises), just using the file you're trying to add, or just using the other person(/people)'s file. If you and the other person making changes were working on different parts of the file, the merge function works great. In the more likely scenario, however, you and your teammate(s) were trying to fix some bug, and both thought you had the solution to it, so who's do you go with then? Of course both people would just use the file they tried to commit, because they both think they are right. This works fine if they are, in fact, right, but if they aren't, people get unhappy when you overwrite the work they've been doing.
The last problems I'm going to talk about are server problems. I'm not going to go into much detail on these, because I have no idea what causes them or how to resolve them. What I will say, though, is that it is terribly inconvenient when you try to commit something, and it tells you it can't because the server is down. I don't know about everyone else, but when I get error messages regarding servers I pretty much just call it quits, because I have no idea what I can do about it.
Having said all that, I think svn could be a great tool if everyone working on the project was properly instructed in the workings of svn, and also if everyone had their own separate files to work, as to not cause conflicts. I'm not sure if that's actually a very likely scenario, but it would be the ideal one. So despite my own personal problems with it, I'd recommend it if you're willing to take the time to get to know all it's workings, and are fairly adept with computers. Personally, however, I'm going to tie myself to the mast as to resist the allure of its song.
Friday, October 14, 2011
The Companion
At the start of the semester, we were given the option of working by ourselves, or working in a group of two with one of our classmates. I'm sure there are a few people in the class that just detest working with other people, but I'm willing to guess that almost everyone is doing the project with a partner. For me, and I'm sure this holds true for the majority of the class as well, working with a partner, as opposed to on your own, was an easy choice. However, after giving it some thought, I have a few arguments against working with a partner (as well as some in favor of it).
My first problem with working with a partner is that the workload is almost never evenly distributed. This isn't (always) because of one person being lazy, but more often because partners just don't have schedules that allow them to meet regularly. When people work on the same project individually, it makes it a much harder project. For instance, say I write a piece of code that makes perfect sense to me, and is working great. so I hand it off to my partner to use for the next step of the project. He takes a look at the code I wrote, and can't make heads or tails of it. So he emails/calls/texts me to try to understand what's going on with it, and then can maybe get the next part working, if I did a good job of explaining myself. The moral of the story is, working with other people's code is hard when they aren't there to explain it to you, and this causes problems for groups that can't meet.
My next problem is that working together can encourage slacking. When you're doing a project by yourself, you know that if you don't get the work done, it won't get done. When a partner is involved, it's much easier to tell yourself that your partner is going to finish it, or that we can put it off until the day before it's due, because there are two of us. That means we'll finish it in, like, half the time, right? This almost never ends well. If you wait until the last minute, you don't finish things as quickly as you thought you would, and you turn in a crappy project. If you expect your partner to finish things for you, you get an angry partner, which is not good and can lead to issues later on in the project.
But for all that can go wrong with having a partner, there is a reason most everyone chooses to work with one. I believe that reason to be the old expression, two minds are better than one. As cliche as it is, I think it's actually quite valid. Chances are, you and your partner have not had the exact same experience programming, which is a great benefit while writing code. For example, before this class, I had no idea what a regular expression was, and no idea how to write one. I did, however, (as I've said in my previous entry) have a good deal of experience in C++. Conveniently, my partner took a class that worked a good deal with regular expressions, but had had almost no experience with C++. Had we been working alone, we both would have had a much more miserable time trying to get anything done. Working together, however, things actually went quite smoothly.
Despite my arguments to the contrary, I prefer working with a partner. One reason is because of what i mentioned in the last paragraph, but there are a couple I didn't mention as well. Probably the biggest one is that, I much prefer writing code with someone as opposed to sitting somewhere by myself typing for a few hours. When you're coding with someone, you have someone there to make sure you're not writing anything stupid, and perhaps more importantly, you have someone to talk to. A good deal of the friends I've made in the computer science department have been a direct result of working on a project with them, and that wouldn't happen if I was working by myself.
To summarize, when working with a partner, there is an off chance that you might not put out the best work you possibly could. But there is a larger chance that you put out better work, and could make a friend. Worth it, in my opinion.
My first problem with working with a partner is that the workload is almost never evenly distributed. This isn't (always) because of one person being lazy, but more often because partners just don't have schedules that allow them to meet regularly. When people work on the same project individually, it makes it a much harder project. For instance, say I write a piece of code that makes perfect sense to me, and is working great. so I hand it off to my partner to use for the next step of the project. He takes a look at the code I wrote, and can't make heads or tails of it. So he emails/calls/texts me to try to understand what's going on with it, and then can maybe get the next part working, if I did a good job of explaining myself. The moral of the story is, working with other people's code is hard when they aren't there to explain it to you, and this causes problems for groups that can't meet.
My next problem is that working together can encourage slacking. When you're doing a project by yourself, you know that if you don't get the work done, it won't get done. When a partner is involved, it's much easier to tell yourself that your partner is going to finish it, or that we can put it off until the day before it's due, because there are two of us. That means we'll finish it in, like, half the time, right? This almost never ends well. If you wait until the last minute, you don't finish things as quickly as you thought you would, and you turn in a crappy project. If you expect your partner to finish things for you, you get an angry partner, which is not good and can lead to issues later on in the project.
But for all that can go wrong with having a partner, there is a reason most everyone chooses to work with one. I believe that reason to be the old expression, two minds are better than one. As cliche as it is, I think it's actually quite valid. Chances are, you and your partner have not had the exact same experience programming, which is a great benefit while writing code. For example, before this class, I had no idea what a regular expression was, and no idea how to write one. I did, however, (as I've said in my previous entry) have a good deal of experience in C++. Conveniently, my partner took a class that worked a good deal with regular expressions, but had had almost no experience with C++. Had we been working alone, we both would have had a much more miserable time trying to get anything done. Working together, however, things actually went quite smoothly.
Despite my arguments to the contrary, I prefer working with a partner. One reason is because of what i mentioned in the last paragraph, but there are a couple I didn't mention as well. Probably the biggest one is that, I much prefer writing code with someone as opposed to sitting somewhere by myself typing for a few hours. When you're coding with someone, you have someone there to make sure you're not writing anything stupid, and perhaps more importantly, you have someone to talk to. A good deal of the friends I've made in the computer science department have been a direct result of working on a project with them, and that wouldn't happen if I was working by myself.
To summarize, when working with a partner, there is an off chance that you might not put out the best work you possibly could. But there is a larger chance that you put out better work, and could make a friend. Worth it, in my opinion.
Tuesday, September 27, 2011
The Journey Begins
My first expedition into programming started with C++, from which I learned much about loops, and how to use them. After that voyage ended, I decided to take off on a journey with scheme, in 1901, and promptly disregarded everything i had ever learned about loops, and object-oriented programming as a whole. That is, until I was asked to come back to the land of C++, and be a TA.
My time as a TA has, if nothing else, made me proficient at debugging C++, and making heads or tails of nonsensical code. This, I believe, shows when I write code myself. I generally try to make it as easy to understand as possible, because I know what it's like to try to read code that's essentially gibberish. So, in that area of programming, I'm feeling pretty good. Comments and I, on the other hand, have not had a very good relationship.
When I first started programming, my thought process was that, all we care about is the finished product. That whatever we write functions as it should, and that it doesn't really matter too much, how we make it work. So naturally, I found commenting to be an utter waste of time. No one was going to have be doing anything with my code after it was done anyway, so why comment anything? Since that time, I've come to realize that people will, in fact, have to read my code at some point, and that reading code without comments sucks really badly when you don't have the person there explaining what the thought process behind the code was. But just because comments and I understand each other now, it doesn't mean we're on speaking terms. I still don't use them as much as I should, but I, at least, know that I should be using them more, and that's a start.
So, pretty much what I was trying to say in this post was, I'm pretty good at writing code that, itself, is fairly easy to understand. However, this is counteracted by the fact that the I don't utilize comments as well as I should be, leaving me with an end result of most likely, only mildly frustrating code to read. I'm hoping, by the end of the semester, to be able to write code that even engineers can follow.
My time as a TA has, if nothing else, made me proficient at debugging C++, and making heads or tails of nonsensical code. This, I believe, shows when I write code myself. I generally try to make it as easy to understand as possible, because I know what it's like to try to read code that's essentially gibberish. So, in that area of programming, I'm feeling pretty good. Comments and I, on the other hand, have not had a very good relationship.
When I first started programming, my thought process was that, all we care about is the finished product. That whatever we write functions as it should, and that it doesn't really matter too much, how we make it work. So naturally, I found commenting to be an utter waste of time. No one was going to have be doing anything with my code after it was done anyway, so why comment anything? Since that time, I've come to realize that people will, in fact, have to read my code at some point, and that reading code without comments sucks really badly when you don't have the person there explaining what the thought process behind the code was. But just because comments and I understand each other now, it doesn't mean we're on speaking terms. I still don't use them as much as I should, but I, at least, know that I should be using them more, and that's a start.
So, pretty much what I was trying to say in this post was, I'm pretty good at writing code that, itself, is fairly easy to understand. However, this is counteracted by the fact that the I don't utilize comments as well as I should be, leaving me with an end result of most likely, only mildly frustrating code to read. I'm hoping, by the end of the semester, to be able to write code that even engineers can follow.
Subscribe to:
Posts (Atom)