Wednesday, 26 September, 12 

Testing and Git Wednesday, 26 September, 12 Today I’m going to be talking about a few methodologies/technologies that are extremely important in industry, but also for academics. It’s often quite unfortunate how students miss out on learning tools like these. They can save you tons of time and grief if you take a few hours to sit down and learn them. More often than not, the time you spend learning and using these tools pays off far more in the future. 

Manual Testing Wednesday, 26 September, 12 So, first let’s talk about testing. Surely by now, you’ve had at least one or two programming assignments. Typically you go about it by putting something together, running it, manually entering things seeing what the results are, and figuring out where you went wrong. This works for a while and on small projects is alright. It’s not great, because you are wasting tons of time continually entering the same stuff over and over again, but it works. 

(›°□°ʣ›ớ ᵲᴸᵲ Wednesday, 26 September, 12 After a while though, you’ll get to some big projects and you’ll have it working. But you’re not done, you need to add some more functionality, or perhaps want to make some changes for bonus points, or even to make your solution simpler! You go in, change some stuff and... shit. It’s not working anymore. Since it was a huge chunk of work and you weren’t able to test continually because manual testing sucks, you don’t know where you made the mistake. You may now flip tables. 

It Gets Better Wednesday, 26 September, 12 But it doesn’t have to be this way. As we get older we realize the errors we made and come up with better ways to solve this. More often than not, it’s in our best interest to come up with a way of automating testing so we can get a quick feedback loop about the changes we’ve made to our system. 

JUnit Wednesday, 26 September, 12 Now I assume all you poor souls are using Java for your assignments, so I’ll talk about the defacto testing suite, JUnit. JUnit is built around the concepts of testing based on publications from authors such as Kent Beck. Our goal is to break out program into small pieces (hence units) so that we can verify the parts work in isolation. Once we are confident our small pieces work, we can combine them into larger pieces, which we also test as a unit. If we are smart and keep our code nice a tidy, changes to a unit should have little to no changes on other parts of the code. 

Wednesday, 26 September, 12 Here, we have a typical JUnit test. In this case we are using JUnit 3, which comes with a few features such as annotations for defining tests and such. In this case we want to verify that one of our objects acts in a certain manner. We put together a bunch of test cases, that each test a tiny part of the code. Typically the smallest aspect is a function or how a function would affect the smallest piece of state for the object in question. As we can see, in our case we’re verifying how some values has an effect on a monsters faintedness. 

I can haz techology? Wednesday, 26 September, 12 Now, this is all well and good, but we still need a way to run this test case and all the tests we’ll surely build over the course of our projects. The easiest way to do this is via automation. There are plenty of tools, for all platforms that make this exceptionally simple. 

Ant Wednesday, 26 September, 12 In our example, I went with the tool called ANT. It’s a java build system, that allows us to specify how a project is to be built. Using a domain specific language, we are able to tell the tool what what things are relevant to it’s interests, how they are put together and what to do with them. 

XML is Like Violence If it hasn’t solved your problem, you’re not using enough Wednesday, 26 September, 12 Unfortunately, with ant, their DSL of choice was XML. Though it’s pretty impressive the stuff you can do with ant. For example, a few years back I had put together a procedural build system for a project I was working on. It was kinda neat, but I never want to have to do that in my life again. XML is gross, but XML with if/else logic is worse! 

Wednesday, 26 September, 12 So, with my build file put together you can run various tasks such as the test task which compiles all of our code and tests. It then proceeds to run all of our test classes to verify that they pass. In our case the tests didn’t pass, and ant informs us what went wrong. 

Mac / Linux Wednesday, 26 September, 12 Now, if you are using Linux or Mac, getting ant to work is super straightforward. On mac it’s pre-installed on the system. Wooo done. On linux, if it isn’t pre-installed, it can be fetched via your package manager. If you’re on Ubuntu it’s probably as simple as apt-get install ant 

Windows ¯\(π)/¯ Wednesday, 26 September, 12 If you’re on Windows. Sorry, I have no clue. I only really use the OS for gaming nowadays. There’s probably something online that tells you how to get it set up. All I know is you’ll probably need to declare some environment variables and add the location of the ant binary to your Path. Have fun! 

Wednesday, 26 September, 12 Alright, so now that we are done talking about testing. Let’s walk through a simple example of writing some tests and getting some code that works. In our example, what we’ll be doing is taking an input sentence and turning all words that are 3 letters or less into upper case. It’s a pretty simple example, but I just want to show how to go about writing some tests. 

Back that Code Up Wednesday, 26 September, 12 So, now that we are in the groove of testing things. Let’s talk about adding even more confidence to our coding. One thing that is awesome, is being able to go into a project and just break things in an attempt to make them better. Whats even more awesome is being able to change our minds if we realize we made a terrible decision. 

THIS IS NOT VERSION CONTROL! Wednesday, 26 September, 12 While you may think that having a different copy of your file for each “good version” you have. This kinda doesn’t work after a little while. << click >> Also, it’s pretty ghetto and can get pretty confusing after a while. We’ve had tools that take care of versioning our source code for decades. It’s time you should learn how to use them. 

Meet Git Wednesday, 26 September, 12 

Distributed Wednesday, 26 September, 12 

svn Client Client git Client Client Wednesday, 26 September, 12 

Simple Wednesday, 26 September, 12 

Going Solo? Wednesday, 26 September, 12 

git init Wednesday, 26 September, 12 Of course before we can get started, we need to have our git repo initialized. The beauty of git, is this is all you need to do. Run this one command and you’re now setup for versioning your source code. 

git add Wednesday, 26 September, 12 Once we’ve been working on some stuff we want to get it into version control. This command doesn’t actually commit it quite yet. It adds the code to the “staging area”, think of it as preparing an envelope before you seal it and send it off. 

git commit Wednesday, 26 September, 12 This is where we *actually* add stuff to our git repository. This will take your data, and version it. Essentially we determine what’s changed and take note of that, also we generate a “unique id” for the commit. This ensures that we can always reference that commit in the future by simply asking to view it by it’s id. 

git push Wednesday, 26 September, 12 Let’s say you’ve gone and setup another git repo somewhere. This could be on a server you run, or github. Running this command gets that code up to the server for others to easily fetch if they need to. 

git pull Wednesday, 26 September, 12 The opposite of push. This command is secretly two git commands mashed into one. What it will do is go out, fetch the changes then merge them. Often you’ll use this like such git pull origin master Which would take any new changes to master branch located at origin. 

git rebase Wednesday, 26 September, 12 Sometimes, you’ll end up with a history that’s a bit messy. You’ve each little step you make, you’ve committed, but now you want your commits to look a bit prettier. Perhaps you just want to merge all your changes into a single patch since they’re all related to a feature. Or... you have terrible commit messages. 

Wednesday, 26 September, 12 

Collaborating? Wednesday, 26 September, 12 Now, for those of you who have been working on team projects, surely you’ve had to merge a bunch of changes you both made together. If you’re lucky, you both worked on separate files and the merging is pretty easy, but even still it sucks. We’ve had software that can do all this for us, why don’t we use it? 

git branch Wednesday, 26 September, 12 Now, the number one cardinal sin which makes merging a disaster is everyone working on the same branch. Merging your code will be just as complicated, and backing out when you mess up may be near impossible and or extremely scary. This is where branching comes in. <> 

git rebase Wednesday, 26 September, 12 Again, you can use rebase for your projects. In this case, what you can use rebase for is, to rewind all your commits onto a new master so that when you merge your branch it’s a clean merge and your history stays really pretty. 

mac.github.com windows.github.com terminal Wednesday, 26 September, 12 

Hosting?! Wednesday, 26 September, 12 

Github Wednesday, 26 September, 12 

github.com/edu Wednesday, 26 September, 12 

Venture Forth Wednesday, 26 September, 12 

Make Something Wednesday, 26 September, 12 

Wednesday, 26 September, 12 

@chris_saunders csaunders Wednesday, 26 September, 12