Week 13 - Thanksgiving Break (Nov 19 to Nov 25)

This past week was Thanksgiving week and that means that we only had one day of class. Unfortunately I couldn't leave campus before Wednesday evening, due to a computer graphics project which for some reason I was unable to get to compile on either my Windows or Linux machines.

Anyway, during the break, I was able to find some time between eating and socializing with my family and friends to try to digest the project. I got a good start on the ConwayCell and FredkinCell classes but I'm not sure I really have a sound strategy for the Cell container class. I think I'll be able to figure it out but I'm hoping for a bit of a class discussion to recap the intended function of Cell, since that's obviously the core challenge in this project, and I want to make sure I understand it before I spend a lot of time trying to implement it and later finding out that I did it totally wrong.

---

This class has won me over as a convert from Mercurial to Git (in certain situations). I still feel the same way about Mercurial, though: it is much easier to learn, it is much simpler to accomplish basic tasks, and it works infinitely better on Windows for much less effort. However, I was working on a project in the Linux computer lab and since my Windows dev box crashed this week, I knew I would only be working in Linux. So, even though all my other graphics projects used Mercurial, I used Git for this one, and found that the power and flexibility it gave me was worth the extra complexity in the commands.

The use case for Git in this situation was more like insurance that I would always have a recently saved, working version of the project, which incrementally implemented more features. Essentially, in this case, there would be no branching and merging, and it was unlikely I would want to revert, so I was using it for its most basic features. Once you start getting into the more complex stuff, I think that the analogy

Mercurial : Git :: Python : C++

You give up a bit of power for expressiveness, but when you need to execute complex tasks quickly, the expressiveness is what you are going to care the most about.

Having gotten comfortable with both systems, I feel like there is actually very little difference in the actual functionality, and my preference for which one to use is going to depend mostly on the project's platform. If I'm on Windows, I will still hands-down prefer Mercurial. On Linux, it will depend on what I need my VCS to do for me, and how I plan to use it.

Week 12 - Taking it Easy (Nov 12 to Nov 18)

This past week was pretty mild across all of my classes. I got to celebrate my birthday in peace, and since the deadlines for my projects are somewhat more spread out this time around I finally have a chance to relax and work through the projects relatively slowly. I can finally be careful not to miss out on the details.

I'm enjoying the discussion in class, although if you asked me to group the lectures into one phrase I wouldn't be able to say, exactly. I guess that means I need to review the material a bit more.

I'm looking forward to working on the next project alone. Compared with working alone, pair programming has been more interesting, in many cases more fun, and sometimes more productive. However, with Thanksgiving break coming up I think it will be easier for me to work on the project on my own time rather than try to squeeze in time to work with someone else. And this will give me a chance to see how programming on my own for this class stacks up against pair programming. I imagine I will struggle a bit more, but I am looking forward to the challenge.

---

My desktop computer's HDD is malfunctioning a bit, but it hasn't been too much of a problem yet. I'm keeping regular backups in case of imminent failure and I've ordered a replacement. I'm just not looking forward to having to set up my computer from scratch again in the middle of the semester. It shouldn't take too long but it's definitely time that could be spent studying or working on my projects. I hope all goes well with the hard drive replacement and OS reinstall.

Week 11 - Private Testing (Nov. 5 to Nov. 11)

Another week gone. I'm glad to be done with the second test. The most recent project was pretty rough to get through as I had several projects due Monday, Tuesday and Wednesday evenings, in addition to the makeup test on Monday. Another thing which made this project somewhat difficult to get through is that I had implemented a more complex form of this same project in CS 315H a few years ago.

Fortunately, my partner Zesen was very accommodating of my schedule and we were able to complete the entire project without too many hangups.

I enjoyed the design component of this project. I would have expected that more of this course would involve designing classes and actually writing code in object oriented style, but the amount of experience I'm getting with C++ is also very valuable, even if it's not precisely what I thought I was signing up for.

My birthday is Tuesday, so I'm happy that this week is going to be relatively light for once.

---

I read a blog post about how unit testing private functions is supposedly evil. The primary argument seems to be that you shouldn't care about implementation details when testing, but I think that is a somewhat closed-minded approach. There are many algorithms that have a very simple public interface but which might contain relatively complex components in some implementations that should be tested individually. It could be rather difficult to know if the test of the public interface is getting good code coverage, or it may be extremely difficult to construct tests which adequately test the nested components. More likely, the algorithm is so complex that in order to make it readable, and thus maintainable, you would want to refactor the method into several utility functions. Sometimes refactoring makes sense because a number of public methods may have to handle the same functionality and thus refactoring private methods allows for code reuse, which is always a good thing.

About that latter point, the writer of the blog had stressed that if you find the need to refactor relatively complex behavior into private methods, why not refactor that same functionality to public methods in a helper class, so that the functionality can be tested in that way? I can't even think how to rebut that point except that the author seems to be missing the point. Some of these private methods might modify the state of the object directly, and do so in such a way that calling these functions without executing any other part of the algorithm might leave the object in a bad state, or a state which doesn't make sense from any external interface.

So yes, I agree that unit testing functions which are not part of a public interface will break encapsulation, but it seems that this author (and many others) are saying that these methods shouldn't be tested at all!

I think that any sufficiently complex implementation warrants tests of one kind or another. Perhaps I can simply write a static method, check(), which runs a bunch of "unit tests" on the private methods of a class. Calling this method will create instances of the class as necessary and test behavior of the implementation details that warrant testing. The method will return true if the tests all pass, and the method will be meaningless to anyone who wants to just use the class rather than verify that it passes its own correctness checks.

Of course, this method could be removed or conditionally-compiled out in production code to clean up the interface. If it is removed though, the information about the correctness tests on the class disappears and this seems like a poor option. I wonder why no one has devised a test framework which allows the testing of private methods, even if the philosophy seems to be that it would be a bad idea. If it's such a bad idea, shouldn't developers be allowed to shoot themselves in the foot if they so desire? I hardly see how this would be the case, but it seems there is enough of an argument for unit testing private functions that the functionality shouldn't be so easily overlooked.

Here's an article which summarizes the pro's and con's of private testing:

http://bytebaker.com/2009/02/13/testing-private-methods-or-not/

I think my final opinion on the matter is going to be the one which seems most in line with the unit testing philosophy, and is the opinion that I started off with: "Anything that can break, should be tested." Furthermore, those tests should be as direct as possible and not have to go through the middle layer of a public interface, if the code in question is in fact a private method.

Week 10 - Fall Back (Oct 29 to Nov 4)

This program has forced me to look at things in a new way. I disagree with the design not through feeling that the expected implementation is wrong but that it lacks the kind of features I would expect to see in a reasonably complete program. I feel like the structure of the programs in this class require a minimum of implementation work and the amount of emphasis on testing is taking us away from the actual concepts at hand now. At first, it was good to have us focus on unit tests, but now the fact that unit testing is mostly a pain has caused me to limit my designs in some pretty serious ways.

In the real world, would you really unit test a method with a trivial function? Probably not.

Anyway, the make up test was once again moved from Friday to Monday. This is again outrageously inconvenient for me with the mass of projects that I typically have due at the beginning of the week. This time my project deadlines are going to keep me from studying for the test, or studying for the test (and taking the test) will prevent me from making my deadlines. I know there's not much you can do but to plan ahead but when every minute of your week is already absorbed in other school things there's not much you can do.

Senior year as a double major sucks because even if you take the minimum number of hours possible, you still don't have time to sleep.