A light introduction to Unit Testing using JUnit and Git. Just glosses over the basics and is useful for people new to both ideas (i.e. 1st year university students)
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.
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.
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.
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.
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.
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.
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.
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.
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!
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.
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
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!
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.
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.
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.
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.
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.
*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.
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.
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.
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.
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?
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. <<Draw pictures to show how it works>>
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.
csaunders
syumai
mototakatsu
tanakahisateru
rainerhahnekamp
tasuku43
myamagishi
kentaroutakeda
kirik
onopon
kimura_m_29
.jpeg){kind=avatar}
arthur1
mashirou1234
mraible
eileencodes
rasmusluckow
ufuk
csswizardry
samanthasiow
geoffreycrofte
palkan
vanstee
marcelosomers
mojombo
bryan
