testing

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.

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):

svn: Server sent unexpected return value (405 Method Not Allowed) in response to MKCOL request for '/svn/F11C3081-40/!svn/wrk/5f9b1812-ca24-41bd-95f3-0f07f2abfb3e/project/tags/Iteration2'

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.