面试题与答案

* Automated unit testing requires extra time to setup initially. But it will save your time, if your code requires changes many times in the future.
* A debugger is designed for manual debugging and manual unit testing, not for automated unit testing. JUnit is designed for automated unit testing.

You can write a main() method in each class that needs to be tested for unit testing. In the main() method, you could create test object of the class itself, and write some tests to test its methods. However, this is not a recommended approach because of the following points:

* Your classes will be cluttered with test code in main method. All those test codes will be packaged into the final product.
* If you have a lots of classes to test, you need to run the main() method of every class. This requires some extra coding effort.
* If you want the test results to be displayed in a GUI, you will have to write code for that GUI.
* If you want to log the results of tests in HTML format or text format, you will have to write additional code.
* If one method call fails, next method calls won't be executed. You will have to work-around this.

If we add debug statements into code, it is a low-tech method for debugging it. It usually requires that output be scanned manually every time the program is run to ensure that the code is doing what's expected.

It generally takes less time in the long run to codify expectations in the form of an automated JUnit test that retains its value over time. If it's difficult to write a test to assert expectations, the tests may be telling you that shorter and more cohesive methods would improve your design.

We should test to target areas that might break. set() and get() methods on simple data types are unlikely to break. So no need to test them.

set() and get() methods on complex data types are likely to break. So you should test them.

Test case class contains a setUp() method, a tearDown() method and multiple testXXX() methods. When calling a test runner to run this test class, the runner will execute those methods in a specific order giving the test case class an execution life cycle like this:

setUp()

testXXX1()

tearDown()

setUp()

testXXX2()

tearDown()

You should run all your unit tests as often as possible, ideally every time the code is changed. Make sure all your unit tests always run at 100%. Frequent testing gives you confidence that your changes didn't break anything and generally lowers the stress of programming in the dark.

For larger systems, you may just run specific test suites that are relevant to the code you're working on. Run all your acceptance, integration, stress, and unit tests at least once per day.