Software with a Guarantee

Size: px

Start display at page:

Download "Software with a Guarantee"

April Norman
5 years ago
Views:

1. Unit Testing Software with a Guarantee We ve settled in Objectville for quite some years now. Time for a new and nicer car. But we wouldn t dare buying one without taking it for a test-drive first.

We can isolate tiny units of functionality and test them thoroughly. And we really need to. Because only tested features can be delivered with a guarantee to function properly.

1 1. Unit Testing Software with a Guarantee We ve settled in Objectville for quite some years now. Time for a new and nicer car. But we wouldn t dare buying one without taking it for a test-drive first. How do you know your software works? The only way to be absolutely sure is by playing around with it. Using it, and watching it to see if it behaves as required. Right? Wrong! We can isolate tiny units of functionality and test them thoroughly. And we really need to. Because only tested features can be delivered with a guarantee to function properly. Classic testing, if done altogether, isn t much fun. Covering all those different circumstances under which our software might be used is a lot of (that not much fun) work. We re supposed to be the software builders, not the users playing with it. Let s see if we can change the way we test software. Perhaps we can even make it fun. this is a new chapter 1

2 Unit Testing Monday Morning, 9:11 am Broke Bank, one of the most respected financial institutions in the country, has decided to finally go Java with their online banking software. Sharon, CEO at Tedious Software, Inc. gets a call Hi, Charles. What a nice surprise. How are things at Broke? If we what? would like to put in a contract for your big Java Project? You bet. You faxed the details already? All right, I ll get right on it. Talk to you soon! Bye. Fifteen minutes later, Sharon walks into our office asking us to write a bank account class in Javaa as a sample for Broke Bank. The contract depends on the quality of this one chance class. Oh, and as is usually the case, it s needed in a hurry. Deadline: noon, today! 2 Audition Chapter

3 No big deal (for a big deal) Let s get right to this. It s seems almost as easy as a school exercise (or one out of a book). We re pretty familiar with an object oriented approach, so let s follow the classic recipe for building this class. 1. First we have to decide on a name for the class. BankAccount seems like a nice one here. public class BankAccount 2. Next we wonder if BankAccount objects should keep any state. Well, they re sure as!heaven supposed to hold some money, so let s add a variable for this right now. //state private int balance; Remember, we hide state and let behavior drive state for two simple reasons: - abstraction (suppose we migrate to a BigDecimal balance later on) - controlled access (nobody should be able to set his bank account balance, right?) I know, we should provide for a fractional part. But Java hasn t a built in fixed point primitive data type like decimal in C#. So we would have to use the BigDecimal class, as we should never ever use a floating point type for currency.. But let s keep things simple here, for now. 3. Finally, we add some behavior to make the class useful. As specs are still coming in, we ll stick to some good old fashioned deposits and withdrawals. //behavior private void deposit(int amount) balance += amount; private void withdraw(int amount) balance -= amount; you are here 3

4 Unit Testing Testing time That couldn t have been more easy. Before we hand it over, let s play a little with it just to make sure it works fine. For that, we ll need a main-method. public static void main (String[] args) //First we try to make our first BankAccount BankAccount myaccount = new BankAccount(); //We deposit some money myaccount.deposit(25); //And we withdraw a little myaccount.withdraw(5); If everything goes as planned there should be $20 on myaccount. How can we check this? We need a method to return the account balance. Let s add that one right away private void getbalance() return balance; and finish our test //And we withdraw a little myaccount.withdraw(5); //Let s see if everything went fine System.out.println("My account balance, " + "starting with $0, " + "after depositing $25 " + "and withdrawing $5,\n" + "is now $" + myaccount.getbalance() + "."); 4 Audition Chapter

Like a charm. We rule big time. That contract is as good as ours.

Perhaps we can celebrate with a nice bottle of wine.

Sharon said quality was very important. Relaaax!

5 Like a charm. We rule big time. That contract is as good as ours. So let s get this shipped and go to lunch early. Perhaps we can celebrate with a nice bottle of wine. Shouldn t we count our chickens after they hatch? Sharon said quality was very important. Relaaax! We did test everything before we delivered it. Didn t we? May well be! But let s hope for the best. Because we sure didn t prepare for the worst. you are here 5

6 Unit Testing The next morning, 7:54 a.m. Sharon is waiting in our office as we come in. And she doesn t look happy. Here s your software back. There s some terrible bug in there causing negative account balances. Mike: How is that possible? Helena: I told you this was bound to happen! Mike: Well, no negative balances. That wasn t specified as a requirement. Sharon: I don t care how it happened. All I know is that I m looking stupid now to this new prospect. I called in some favors and we ve got a second chance. We can turn in a new version today, again by noon. So I suggest you get started! Mike: We re very sorry. We re on it! Trust us. Sharon: I wish I could. But this time I m going to test it myself before we ship it! Jason: Well perhaps we can prove that everything works fine by showing you our test code. Sharon: What do you mean? Jason: Well I read about this structured way of writing these tests called unit tests. Sharon: Whatever gets the job done. I ll be back in a few hours. And I want quality results. 6 Audition Chapter

7 5 minute standup meeting Mike: Jason: So, Jason, what about those unit tests. Well it s a paradigm shift in looking at testing software. Helena: Shouldn t we focus on solving the bug first? Jason: Peter: Mike: Perhaps. But we ll still need to test if it got fixed, no? I think I know what went wrong. It shouldn t be possible to withdraw more than the balanced amount of money in the account. Exactly! How could we have overlooked this? So all we have to do is write a control statement in the withdraw method. Let s do this. private void withdraw(int amount) if (amount <= balance) balance -= amount; Helena: Shouldn t we do the same with the deposit method? Peter: No. Since it s only adding money to the account. Helena: That means we re done? Mike: Jason: Mike: Jason: We just have to test it. So we have to add some more code to our main method. Not exactly. We need to get rid of that main method! What do you mean? We need to test this! That s where unit tests come in. [Suggestion: Mike could state the fact that messing around with that main method isn t the way to go, as it ll soon start to be one large blob method. Then Jason could reply that unit tests are the answer. ] you are here 7

8 Unit Testing Unit tests So here we are. The classic approach to testing, if there ever was one, has long been some programmer taking his software for a test-spin in some quick and dirty try-out through a main method or some equivalent. The programmer thus inspecting the output from the method when it s run. There are however some serious disadvantages to this approach. 1. Very soon, a main method gets cluttered with code that tests a lot of different things. 2. There s contamination. Typically every code that s written has to build upon the context of everything that s written before. It s basically one big blob method. 3. The sole alternative very often being commenting out some earlier test code or just deleting it before running the whole. 4. When that main method is run, the programmer manually (i.e. visually) has to inspect the output to see if she got what she expected. This is a very tedious and repetitive task, and people make mistakes when something has to be repeated over and over again. Also it s very time consuming and non productive. 5. Also, the main method very often gets distributed along with the software. 6. Hence, testing isn t much fun. It s often reduced to the bare minimum just because programmers want to be creative and produce new code instead of setting up some elaborate test code in a huge main method. 7. A lot of the assumptions made by programmers need to be documented (in the code or somewhere external to the code). The documentation and assumptions are often separated from the code that s making the assumption. Or documentation and assumptions are written in a totally different language altogether (we code in a programming language but document in a natural language or in a visual language like UML). 8. As such, computers can t read the assumptions we make, even if we document them. If they can t read them, they can t check them. When something has to be checked repetitively, how can we cope with that? Who s very good at making formal checks and repetitive tasks? Our computer is! Each programming language can check things (selection choices) and repeat things (iteration loops). So why not give the tedious and repetitive tasks to the computer? Giving tests to the computer takes them out of our hands. Making tests the computers responsibility also means programming them. Programming is a lot more fun than reading output from a screen. 8 Audition Chapter

Wait a minute! And exactly how are we going to tell a computer to read a screen? We don t have to do that. We can just provide the test-code with the expected output.

If they are different, the test fails and we have to alarm the programmer. Ok. And how about the other issues?

9 Wait a minute! And exactly how are we going to tell a computer to read a screen? We don t have to do that. We can just provide the test-code with the expected output. So the test executes whatever functionality it wants to test and compares the expected output with the actual output. If they are different, the test fails and we have to alarm the programmer. Ok. And how about the other issues? Tests should be isolated, repeatable, automated, and so on. real output expected output You re right. There s a lot more to cover. But you know what? Let s just dive in, write our first test and then take it from there. no fail test! == yezz pass test! you are here 9

10 Unit Testing Your First Unit Test To cope with the separation of test code from production code, we ll create a whole new class that we will call BankAccountTester. Why? Because this class... <drumroll /> <crash /> is going to test our BankAccount class. Besides, classes should have clearly outlined responsibilities. public class BankAccountTester Each isolated test will get its own method. private static void testdeposit() BankAccount testaccount = new BankAccount(); testaccount.deposit(20); if (testaccount.getbalance()!= 20) System.out.println ("Oops!"); All test methods then get called from a main method. public static void main (String[] args) testdeposit(); 10 Audition Chapter

11 Q: Shouldn t we provide an else clause to the test? No. If all went fine, there s no reason to bother the programmer. In fact, suppose we have hundreds of tests all writing they passed. This would clutter the output in the console, possibly even hiding failed tests between the endlessly scrolling output. Nonetheless, with a graphical interface we could use controls like a tree view and gather statistics on all tests, failed or passed. That s exactly what we ll get when we start using a test framework. As a matter of fact, the oops message will be exchanged for some contextual description of what went wrong and where it did, what we got and what was expected. Be patient, grasshopper! Q: Why the long name for that test method? Shouldn t method names be short? Because it will only be called once and it should be very descriptive of what feature or unit of functionality we re actually testing. Descriptiveness in this case is of utmost importance. Again, when we ll start using a test framework, we won t even have to call it once. The framework will do it automatically for us. Q: I get it. And we write a test method for every method in our BankAccount class, right? No. Not at all! As we will see, a method can be tested for a lot of different use cases. For instance we could test what happens when we withdraw money when there s enough. But we could also test withdrawal of too much money for the account (more than its balance). And sometimes a test will call several methods of the class under test. So there s a many to many relationship between methods and tests. Q: Why do we call it a unit test? Because, if you reread the previous answer, a test isn t about testing some method. It s about testing a specific piece (a unit) of functionality. Q: Why is the test method static? Because it simply has to be if we want to call it from a static method like main, without creating any objects from this test class. This problem will also get solved automatically if we ll start to use a test framework. Q: Why doesn t the test method have any arguments? A test should be contained and isolated, and certainly not depend on the context of its caller. With parameters it surely would be. On top of that, in a framework, tests should be run automatically by a machine. A machine can t figure out any parameters. Q: What about documenting assumptions? Coming up next! you are here 11

Unit Testing Dissection of a Test Let s refactor our test a bit, making it document any assumptions, and dissecting it to find out each part of its structure.

12 Unit Testing Dissection of a Test Let s refactor our test a bit, making it document any assumptions, and dissecting it to find out each part of its structure. Let s get everything we need to set up private static void testdeposit() and prepare for the test //SETUP BankAccount testaccount = new BankAccount(); int initialbalance = testaccount.getbalance(); int someamount = 20; //EXECUTE testaccount.deposit(someamount); //TEST if (testaccount.getbalance()!= initialbalance+someamount) System.out.println ("Oops!"); This code clearly documents any assumptions we make to call this a successful test. Whatever the balance was, what we deposit should be added. Is what we get after running the functionality under test actually what we expected? If not, make clear the test failed! Go! When everything is set up, we call the functionality we want to test Now, could you write the unit test for withdrawing money under normal circumstances (having enough money in the account)? And what about a unit test to see if nothing gets withdrawn when we try to get more money out of the account then it has on its balance? 12 Audition Chapter

13 Wrapping this up (solution to sharpen your pencil) Here s the unit test that checks withdrawal under normal circumstances (that is, having enough money in the account): private static void testnormalwithdrawal() //setup BankAccount testaccount = new BankAccount(30); int initialbalance = testaccount.getbalance(); int theamount = 20; this assumes a constructor for this test to pass, so code evolves as tests are added! //execute testaccount.withdraw(theamount); //test if (testaccount.getbalance()!= initialbalance-theamount) System.out.println ("Oops!"); and the one making sure nothing happens when we try to take too much money out of the account (more than it has on its balace): private static void testwithdrawingtoomuchmoney() //setup int initialbalance = 10; BankAccount testaccount = new BankAccount(initialBalance); //int unchanged = testaccount.getbalance(); int toomuchmoney = 20; //execute testaccount.withdraw(toomuchmoney); //test if (testaccount.getbalance()!= initialbalance) System.out.println ("Oops!"); so this could have read unchanged as name for this member variable could help document the actual test even more Look how this documents things. It s almost readable natural language. if (testaccount.getbalance()!= unchanged) you are here 13

Unit Testing I m afraid I don t see any benefits here? We re actually writing MORE code. We don t even have the time to fix bugs and keep up with writing production code. Well, don t be afraid.

14 Unit Testing I m afraid I don t see any benefits here? We re actually writing MORE code. We don t even have the time to fix bugs and keep up with writing production code. Well, don t be afraid. In fact that s the first concern every programmer new to all this seems to have. It may very well be that we end up writing more code. And we may even introduce a bug into our tests. But the whole point of writing unit tests isn t so much that we test, because that was what every programmer used to do one way or the other. The big benefit from unit tests is that they actually do their own testing (instead of some poor programmer having to read output to see if all went right). Furthermore, unit tests are isolated from each other, not contaminating each other while running and they are automatically repeatable (as much as you like write once, run many). As we will explore test driven development and emerging design further on in this book, we ll learn that having lots of unit test that are very cheap to compile and run is of key importance. They not only prove functionality but also guard it! Finally, tests let us quantify both work and it s quality in software building. That s all very nice. But isn t this test code just about small, obvious pieces of code that seem just too easy to go wrong? And as many of those unit -things as you might write, they re never going to guarantee bug-free software, right? That s true. We don t have a complete guarantee. But we didn t have that before we started writing unit tests either. But we do have all of the advantages we mentioned above just by restructuring our test-drive code in our main and adding the actual control to the test. A very small step for the programmer but a huge leap forward in building flexible software in a test driven way. Software that will emerge as requirements are gathered and translated into new tests. This example might indeed seem too easy to go wrong. But what if we told you that the bug still isn t fixed? If you didn t realize this yet, perhaps you can see it, now we ve told you? No? Well then even this too easy example might not be as obvious as it seemed at first. 14 Audition Chapter

More to come in Head First Test Driven Development and

ownership Find out Do we really want to engineer software?

what triangulation has to do with building software?

design the color code of unit testing what s the fuzz about

15 More to come in Head First Test Driven Development and Emerging Design Discover the benefits of collective code ownership Find out Do we really want to engineer software? Discover the secrets and patterns of refactoring! what triangulation has to do with building software? the difference between a Yeti and a Yagni about anticipatory design the color code of unit testing what s the fuzz about test coverage, code hygiene and cyclometric complexity What if you wrote tests first, grasshopper? Learn about mock objects, stubs and proxy s Be able to tell your friends all about JUnit and emerging design you are here 15

The name of our class will be Yo. Type that in where it says Class Name. Don t hit the OK button yet.

The name of our class will be Yo. Type that in where it says Class Name. Don t hit the OK button yet. Mr G s Java Jive #2: Yo! Our First Program With this handout you ll write your first program, which we ll call Yo. Programs, Classes, and Objects, Oh My! People regularly refer to Java as a language that