How to Write Tests

First of all like I mentioned last month there are a few different methods for testing. The most important in Java is assertEquals as it gives more helpful output if the test fails. There are other assertion methods and if you want, have a look at the Assert-JavaDoc.

I showed you how to create test cases and the important testing methods so let’s start writing tests. Since JUnit 4 it’s much easier to write tests because you don’t have to care about testsuites and tests don’t need the word “test” in their method name to be recognized as a test. To go on with there are only a few things you have to do to write tests.

Firstly if you want to test complex classes and programs you have to initialize the required objects and their states. To do so the first method in our test case is named setUp and in front of this method you have to write @Before and import the necessary package. This setUp method will be called before each test you execute.

The next step is to write the actual test methods. You create a new test method by simply writing @Test in front of the method, isn’t it easy? Note that it’s considered good style to use method names starting with should or shouldNot and then write what you want to test so that it is clear, what is asserted. Have a look at the following test skeleton to see how this all would look like:

	@Test
	public void shouldBeEmpty(){
		...
	}

Sometimes you like to test if an error is thrown, probably see if the check for meaningless input works. For example if you pop an empty stack there should be an error – and it’s a failure, if there is not! To test this you have to write the expected error right after @Test. It should look like this:

	@Test (expected=AssertionError.class)

Now if and only if this error is raised the test will pass.

Last but not least I’m going to show you an example with a few tests. It’s a very simple and trivial one and it’s not a thing you should write tests for, especially not chained ones, but you should see how it’s supposed to work. In this example I’m only going to test the basic calculation functions with Integers. Therefore I’ll test addition, subtraction, multiplication and division should work correct and the result should always be an Integer.

Example:

public class CalculaterTest {

	public int testValue;

	@Before
	public void setUp(){
		testValue = 0;
		assertEquals(testValue, 0);
	}

	@Test
	public void shouldAddFive(){
		testValue = testValue + 5;
		assertEquals(testValue, 5);
	}

	@Test
	public void shouldSubTwo(){
		testValue = testValue + 5;
		testValue = testValue - 2;
		assertEquals(testValue, 3);
	}

	@Test
	public void shouldMultWithFour(){
		testValue = testValue + 5;
		testValue = testValue - 2;
		testValue = testValue * 4;
		assertEquals(testValue, 12);
	}

	@Test
	public void shouldDivWithTwo(){
		testValue = testValue + 5;
		testValue = testValue - 2;
		testValue = testValue * 4;
		testValue = testValue / 2;
		assertEquals(testValue, 6);
	}

	@Test (expected=AssertionError.class)
	public void shouldRaiseError(){
		testValue = testValue + 5;
		testValue = testValue - 2;
		testValue = testValue * 4;
		testValue = testValue / 2;
		testValue = testValue / 4 * 3;
		assertEquals(testValue, 4.5, 0.00000001);
	}
}

As you can see a lot of the code has to be copied every time which leads to long and hard to maintain tests but next month I’ll write about a cool Framework to improve this tests and to write even better tests.

That’s it for almost this month, “How to Write Test in Pharo” will be online 31^th of October.
Stay tuned and leave comments below.
cheers d3orn

I love meta-programming. I really do. Making the computer not only do what I program it to do, but making it writing my programs just gives you the feel of power and makes you want to shout It’s alive in disbelieving ecstasy. Or something like that.

But that being said, there are some precautions that make meta-programming often quite different from normal programming.

• Care how it works: If you don’t know how a process normally works, you can not dream of interfering with it in a meaningful manner. Sometimes this is rather easy, as for example the macro system of modern LISPs, or in Ruby, sometimes it is quite different from the way you’d normally do, as in Java, and sometimes, it seems more or less impossible – yeah, I’m looking at you, C.
• There is no copy-and-paste: Depending on how easy the programming process is, there might be few if any tutorials and helpful sites out there. Ironically, the more you’d need a helpful hand, the less likely it is that you’ll find it.
• Your code probably won’t be all that self-explanatory, so document it well. Few people are familiar with the Craft, so explain what you do. Depending on your background, you’d do that anyway, but others write their code self-documenting, which relies on others getting the basic idea of what you are doing.
• Expect the unexpected. Ok, this is quite similar to what you would normally do, but in my experience, the WTF per minute rise significantly when dealing with meta-programming.

So… why would you even deal with this? The answer is the usual: to save time and to make hard things easier.

I once wrote a decorator for Python, that automated the generation of a test suite, so instead of setting up these things by hand, you’d just write @Test in front of any test method, leading to more concise and arguably more readable code. A simple note @commutative could generate a test case to check, if f(x,y) is f(y,x) (for a given example at least). Or imagine a Ruby meta class, that automates the generation of a wrapper class by translating most calls with the help of a dictionary. So meta-programming can help you to jump over the boring parts and get to the hopefully less boring parts.

I hope, I encouraged someone to give the meta-weirdness a try.

Cheerio,

zombiecalypse

because we moved to a new house in May we could somehow manage to get into the test phase of so called “digitalSTROM”.

Therefore I like to write about this feature and what possible things you can do with it because I really think this is going to be something very nice in the future.

“digitalSTROM” is a very new technology to program every single electric device in a house with the help of screw terminals and one little server, but before I go into any detail just watch the video below.  (Could take sometime to download)

For more informations about “digitalSTROM” please visit the their page http://www.digitalstrom.org

See the following summary about the most important features:

• dim light without special lamps
• turn off the power in the whole house/building
• control any electrical device via IP
• program different scenarios for different situations

I hade a few thoughts about the use of this feature:

First of all, I really like the idea of having one button near your door turn off all electricity and all devices in your house with one click or on the other side turn on all the things you turned off when you left.

Secondly, it will be possible to start almost any electrical device while you are away from home. Imagine the last days of your holidays and you could simply use a mobile application to start the heater and when you arrive home your house is warm and you feel pleasant. Another thing you could do is to put something (like pizza) in the oven before you leave for work and when you’re on the way home you can start the oven and eat right after.

To go on with I like to mention that with the help of “digitalSTROM” enterprises could save a lot of money due to electrical savings. They could control the heater, light, air conditioner and many more only with the help of a tool – for example they could program it such that all the light turns off at 2′o clock PM.

Finally, the way I would definitely use “digitalSTROM” is to turn on my computer of my server while I’m in the University or away to send/get data or to remote control my devices. I also in favour with the dim feature because a good light ambiance is really helpful for work and for non-work stuff.

That’s it for today, I hope I did have some good ideas and I could tell you what “digitalSTROM” is (mostly with the help of the video). If you have another good way to use it or any other things you like to tell please leave comments below.

cheers d3orn

Imaging a game with many more or less rectangular objects, with huge levels, in which only a small part actually has to be drawn – the rectangular screen. The naive idea of checking all objects if they intersect with the screen is nice – you don’t have to draw all objects, but that can be quite difficult to compute if you have thousands of rectangles.

The question the quad tree tries to answer is the following: Given this set of rectangles, is there a faster way to find all the rectangles that intersect with this one, than to iterate over all of them? Lets call that rectangles.allIntersecting(R)

The basic idea behind the Quad Tree (QT) is to sort out parts of the picture, that can not possibly contain any rectangles hitting R.

Take the rectangle [[0,0],[1,1]] as an example. Can R=[[0.1,0.1],[0.25,0.25]] hit the top right quadrant? Nope, so never mind even checking if there are rectangles in there, that hit R.

The quadtree only checks part of the subtrees for intersections.

Every QT is either a leaf or has exactly four subtrees. Because of the ease of computation, the subtrees divide their bounds in four equal parts. The rectangles are stored in the trees, not the leaves, which are essentially nil.

Let’s start with

tree.allIntersecting(R):=
    hits := rects in self.items that hit R
    for all subtrees s overlapping with R:
        hits.addAll(s.allIntersecting(R))
    return hits

What happens, when a new rectangle is added to the tree? Let’s call that

tree.addRect(rect):=
   if rect hits all subtrees
       self.items.add(rect)
    else
        for all subtrees s getting hit by rect
            s.addRect(rect)

By this, the rect possibly gets stored in multiple places, but that can’t be helped, else one couldn’t be sure, there is no rectangle lingering in another quadrant, that intersects with the screen, but wouldn’t been found.

Adding a tiny rectangle leads to many steps down the tree.

Does that solve the problem? That – as always – depends: The worst case for allIntersecting is the bounds of the tree, thus recursing all the way down. That makes it O(n*4^maxdepth), which is worse than the O(n) of the naive approach. Even worse: there is no upper bound to inserting a rectangle: Imagine adding a very small rectangle [[0,0][epsilon,epsilon]] to the tree. Now it takes O(log₂(1/epsilon)) steps until the rectangle hits a tree’s centre. And that function approaches infinity as epsilon gets small. That’s why QT’s should implement a maximal recursion depth, after which all pending rectangles are just inserted into the tree, no matter if they hit the centre.

However in the average case, there is a fixed size screen that is much smaller than the initial tree. Let’s assume the size of the screen is 2^k times smaller than the tree’s bounds, now we can discard 2-3 trees each step down until the bounds of the next trees are as big as the screen (that is after k steps). We get O(2^-kn4^(maxdepth-k)) runtime – a huge improvement to the naive approach. If we set the maxdepth so that maxdepth=k, we don’t get to feel the problems of the tree at all!

Next time, I’ll show you how I implemented it in Clojure, so stay tuned!

zombiecalypse

today I like to start a new monthly article called “News”. Every month I’m going to write about what I learned, I did and was especially interesting in this month lectures and work.

Because the semester started last Monday I like to share my first impressions and thoughts with you.

I have two very good lectures; the first is about analysis and modeling of business processes. I’m very excited to learn more about many different ways to model processes and other things. We are going to learn UML, petri net and many more. Although it’s a business administration lecture it will be a great help in the future for contract driven design and I can’t wait to learn more!

The second one is introduction to software engineering and in my opinion this is one of the most interesting lectures in computer science so far. We are going to make a Web-App as exercise, I don’t know what we are going to program but I’m really excited because I never made a Web-App. The first lecture was about engineering as an iterative process.

And good news I started to like mathematics again, linear algebra is interesting if you make the homework and learn for it but I’ll have a lot of fun with it this year and I hope I’ll pass xD.

At the moment I do work a lot on excercises and blog articles (yes you may see this soon) and because this month different visitors skyrocket to over 400, I like to increase my frequency of blog articles even more, starting with this new column. I’m currently aiming for over 1000 visitors a month, you could spread the words.

About SCodeBubbles we are going to have a meeting next week sometimes and zombiecalypse is currently trying to get a working quadtree for Pharo (Smalltalk). To go on with I’m playing around with Seuss (Dependency Injection framework for Pharo) to get more used to Smalltalk. You will see an article about Dependency Injection (DI) soon.

That’s it for September 2010 News, I like to post this News every month but I’m not sure yet which date it will be but I’ll tell you if I fixed a date.

Leave comments below

cheers d3orn

today I recommend you’d take a day off - and not only from coding but from the computer all together. Don’t sit behind your desk staring into shiny computer lights, stirring the chunk of plastic, that is your mouse, and hacking on the keyboard. Just go out, read a book (no work, no learning), watch a movie or get a drink with some friends.

There are a lot of things you can do, but start with shutting down your computer.

Why do I recommend this to you?

That’s because if you take a day off today your mind can rest from your task, your (brain-) muscles and you will be more relaxed tomorrow. Therefore you can work much better and even more efficient. In addition you might even come up with a solution or an idea for a problem you have tomorrow because you’ll have a different point of view on it and you’re more relaxed. Plus: You’ll feel much better.

Believe me it does help a lot and it’s not only for your work, it’s good for you and your social life (Yeah we got one^^).

Hey you’re still reading this article! Shutdown and do something else!

cheers d3orn

this month topic is tests, there are many different kinds of tests and because I like to have more but smaller articles I’m going to split this article up into more then one article. As a result you will probably see my first ScreenCast I ever made, I like to make a Screencast in the last article about this topic because I want to show you a good example.

I’m going to split this articles up into:

• UnitTests
• How to write Tests in Java and Pharo
• JExample
• Write Tests First

As you can see I’m going to start with UnitTests today.

UnitTests

What are UnitTests?

A unit is the smallest piece of source code you can test and therefore a UnitTest is a method to determine if such an Unit works as intended.

In most programming languages there are tools to write tests. For example in Java you can use assertTrue, assertFalse and assertEquals to create tests or to check conditions in you’re methods (more about this later) and in Smalltalk (Pharo) you do have self assert. To go on with there are test frameworks like JUnit and SUnit which helps you organize and running you’re tests.

With the help of these methods you can start to write tests, in Java you have to create a JUnit Test Case in Eclipse and import the java.util.assert.* lib. Please notice that I’m using JUnit 4 and not JUnit 3, you should always check the used version before running a Test Case. To check this in Eclipse you right-click on the Test Case -> Run As -> Run Configurations… and in this window you can select the test runner you like.

To go on with there are only a few rules for writing UnitTests:

• KISS (keep it short and simple)
  
• At least one test per method
• test coverage of approximately 60% or higher (more about test coverage later)
  
• tests shouldn’t be longer than ten lines
• tests should represent a scenario how the unit is used

Tests should be written during the development phase or the debugging phase. During Development you should create tests whenever you encounter one of the following problems:

1. You need to add new functionality
2. You need to redesign your software to add new features or adapt to new requirements

In the first case it’s very helpful to write the tests for this new functionality first and then implement the functionality, I’ll cover this in the third article. In the second case you already have a working program and you want to add new features, you therefore should refactor the old version in small, very small steps and after each of these steps you should run the tests you have again. You then have to fix everything that’s broken and when all test pass you can proceed with refactoring. As you can see tests will help you a lot during the development phase of a project but you can also use them during the debugging phase.

During Debbuging whenever you encounter a bug or a defect in your code you should write a test to demonstate that bug and as soon as this test passes you’re bug is fixed!

That’s it for this month and I hope you enjoyed the reading ^^

It’s a big goal of mine to show all of you that tests are good, a lot people I know think that tests are only a waste of time and not worth to be written. I think UnitTest will help you a lot in the future to maintain or refactor a program and you definitly get your invested time back. The best part of UnitTests is, once written, you can run them as many times as you want whitout using much time.

Please leave comments below and stay tuned for the next months article about JExample .

cheers d3orn

zombiecalypse wrote an article about “How to Learn a New Language” earlier. He brought up the idea of “Fooling Around” and although I haven’t learned as much languages as zombiecalypse did, I’d like to write about how I do fool around with a new language.

First of all when you start learning and fooling don’t try to understand everything because it’s not necessary you do. There is one rule which is perfect for the start and also for every object-oriented progamming language: I don’t care how it works as long as it works! To go even a step further the receiver should care but not the sender, that’s you. Therefore fool around and don’t care how it works just try to make a little program. When you’re done go on and make another more complex program and probably start to look a few things up.

There is only one important thing left to say. Just do something get your fingers up, write code or do something you wanted to do for a long time but just don’t be lazy. You can’t learn a language when you don’t start to do something!  Sometimes it’s hard to start but let me tell you one thing, it’s definitively worth it.

By the way, I made a little twitpoll a few days ago to see about which topic you would like to read an article in the future. As a result of this poll I’m going to write about “Take a Day Off!“. You’re opinion is very important for me so leave comments, vote in the twitpolls or just send me an email.

cheers d3orn

So you can program without ever changing anything. But that begs the question: Why would you do that? It seems quite counter-intuitive. Yeah,welcome to the wondrous world of functional programming, where nothing ever changes!

Techniques

Memory

What is the clockrate of the computer you are working on? Chances are, it’s about 2.5GHz. However you probably got at least two cores, the newer the more. That’s the trend, you don’t get faster processors, but you get more. There are problems with that. If you can do more things in parallel, but want to do something as fast as possible, your CPU power does not just add. And if something changes, it can not spread very well across processors, because different parts of the program might change the same value at the same time making them inconsistent. Or you lock access while you access it, but then you’d have to wait.

Or you don’t change it at all and copy it in a smart way. You’d expect this to make your code even slower, but scientist did a great job inventing datastructures, that make this easy. In fact, you’ll probably never see a case that would make your code more than a factor of log(n)slower, as experiments have shown.

As memory access is the performance bottleneck today, being able to perform it in parallel helps quite a bit.

Remember your Calls

Another cool bit is memoization. To show students why recursion sucks, professors like to use the following example

Recursive version

def fibonacci(n):
	if n < 2:
		return 1
	else:
		return fibonacci(n-1)+fibonacci(n-2)

Iterative version

def fibonacci(n):
	a = b = 1
	for i in range(n):
		a,b = b,a+b
	return a

The first one is usually slow as hell, because you keep computing the same numbers over and over again. But as fibonacci is just dependent on n, you could just make a table for it and only compute the number, if it hasn’t been done already. That makes the performance the same as the iterative approach. We call that memoization and you can perform that only if your function is pure, because otherwise, there might be other influences on the outcome, which would not be taken into account with the caching. If the function is pure however, you can use it for all of dynamic programming without real performance penalty.

Being Lazy pays off

Quite possibly my favorite part is laziness. If the return value of a function call does not depend on its environment and thus the precise moment, in which it is called, you don’t need to compute it right away. Wait ’til you actually use the value and maybe, you don’t even need to calculate it at all. This extends so far, that you can simply make an infinitely big datastructure, for example a list of all natural numbers.

That’s it for today, but there might be other articles following up on this topic.

Have fun!

Zombiecalypse