JUnit In Action读书笔记(1)

Part1 JUnit distilled

chapter1 will teach you what the JUnit framework is and what problems it solves.
chapter2 will take you on a discovery tour of the core JUnit classes and how to best use them.
chapter3,you'll practice your new JUnit knowledge on a real-world example.
chapter4 steps back and explains why unit test are important and how they fit in the global testing            ecosystem.There,the Test-Driven Developement methodology and provides guidance on measuring        your test coverage.
chapter5 demonstrates how to automatice unit testing using three popular tools:Eclipse,Ant,and maven.

Chapter 1 JUnit jumpstart

we code,compile,run,test again.
Most of us will quickly develope a pattern for our informal tests: We add a record, view a record, edit a record,and delete a record.Running a little test suite like this by hand is easy enough to do;so we do it.Over and over again.

1.1 Proving it works
    Here's a generic description of a typical unit test from our perspective:"Confirm that the method accepts the expected range of input,and that the method returns the expected value for each test input".

    In this chapter, we'll walk through creating a unit test for a simple class from scratch. We'll start by writing some tests manually, so you can see how we used to do things. Then, we will roll out JUnit to show you how the right tools can make life much simpler.

1.2 Starting from scratch

    public class Calculator{
        public double add(double number1, double number2){
            return number1 + number2;
        }
    }

    Yet testing anything at this point seems problematic.You dont even have a user interface with which to enter a pair of doubles. You could write a small commandline program tha waited for you to type in two double values and then displayed the result.Of course, then you would also be testing your own ability to type a number and add the result ourselves. This is much more than you want to do.You just want to know if this "unit of work" will actually add two doubles and return the correct sum.You don't necessarily want to test whether programmers can type numbers!

    You could also run the program again later to be sure the method continues to work as the application grows.

    So what's the simplest possible test program you could write?How about the simple TestCalculator program shown in listing below?

    public class TestCalculator{
        public static void main(String[] args){
            Calculator c = new Calculator();
            double result = c.add(10,50);
            if(result != 60){
                System.out.println("Bad result: "+result);
            }
        }
    }

    But what happens if you change the code so that it fails?(这个changed是怎么change?改哪?这个fails是指哪?是指TestCalculator?还是哪个Test类?).You will have to carefully watch the screen for the error message.(噢,现在明白了些,是说若失败后的有什么信息来告诉你失败了)．You may not have to supply the input,but you are still testing your own ability to monitor the program's output.You want to test the code,not yourself!

    The conventional way to handle error conditions in Java is to throw an exception.Since failing the test is an error condition,let's try throwing an exception instead.

    Meanwhile,you may also want to run tests for other Calculator methods that you haven't written yet,like subtract or multiply. Moving to a more modular design would make it easier to trap(这个trap是trap啥的？怎么trap呢？是catch吧？) and handle exceptions and make it easier to extend the test prgram later. the following shows a slightly better TestCalculator program.

    public class TestCalculator{
        private int nbErrors =0;
        public void testAdd(){
            Calculator c = new Calculator();
            double r = c.add(10,50);
            if(r != 60){
                throw new RuntimeException("Bad result: "+ result);
            }
        }

        public static void main(String[] args){
            TestCalculator t = new TestCalculator();

            try{
                t.testAdd();
            }catch(Throwable e){
                t.nbError ++ ;
                e.printStackTrace();
            }

            if(t.nbErrors > 0){
                throw new RuntimeException("There were "+t.nbErrors + "error(s)");
            }
        }
    }

1.3 Understanding unit testing frameworks
    these seemingly minor improvements in the TestCalculator program highlight three rules that (in our experience) all unit testing frameworks should observe:
        Each unit test must run independently of all other unit tests.(这就是说add和multiply得分开吧)
        Errors must be detected and reported test by test.（这个没什么理解上的困难）
        It must be easy to define which unit tests will run.（这个怎么来决定？怎么叫哪一个tests来运行呢？）

    The "slightly better" test program comes close to following these rules but still falls short. For example, in order for each unit test to be truly independent, each should run in different classloader instance.(为什么说要在不同的classloader　instance里呢？这个"each"是指TestCalculator呢还是那个Calculator类呢?难道说Calculator这个类在同一个Classloader instance就不能independent?而在多个Classloader instance里又怎么可以independent呢?)

    Adding a class is also only slightly better.

    The most obvious problem is that large try/catch blocks are known to be maintenance nightmares.You could easily leave a unit test out and never know it was't running!(这个leave a unit test out是什么意思?噢,明白了,这句话的意思是说"你很容易就会遗嘱一项单元测试,而你甚至从来都没有意识到这项测试被漏掉了!")

    It would be nice if you could just add new test methods and be done with it.But how would the problem know which methods to run?

    -->a simple registration procedure.A registration method would at least inventory which tests are running.("你应该有一个简单的注册过程,至少会有一个注册方法来盘点要运行哪些测试.")
    
    Another approach would be to use Java's reflection and introspection capabilites.A problem could look at itself and decide to run whatever methods are named in a certain way -- like those that begin with the letters test, for example.

    Happily, the JUnit team has saved you the trouble. The JUnit framework already supports registering or introspecting methods. Is also supports using a different classloader instance(这个classloader instance很有必要么?还是不理解.........) for each test, and reports all errors on a case-by-case basis.