Testing & Debugging

Question 1

Unit testing

Answer 1

A level of software testing where individual units are tested. (i.e. Testing a method by itself, isolated from the remainder of the program.) The hope is that once the individual pieces are tested and verified to be working, then the likelihood of the overall project working becomes much higher. For Java programs, a unit is usually a method.

Question 2

Test coverage / Code coverage

Answer 2

A measure of the amount of source code that has been executed during testing, typically provided as a percentage of lines covered. When executing the set of tests, if any line of code is executed, that line is said to be covered. You can use a tool like EclEmma to measure this.

General practice is to strive for at least 80 percent coverage (higher is obviously better), but remember that 100 percent coverage does not mean that you have handled all possible test cases! It is not uncommon to have more than one test to cover a given unit. That is, it is possible, and is often recommended, to have tests that account for both expected and unexpected behaviour of a given unit.

Question 3

Black-box testing

Answer 3

Testing a method without knowing its implementation.

Question 4

White-box testing

Answer 4

Testing methods by taking their implementations into account, in contrast to black-box test ing; for example, by selecting boundary test cases and ensuring that all branches of the code are covered by some test case.

Question 5

Boundary test cases

Answer 5

A test case involving values that are at the outer boundary of the set of legal values. For example, if a method is expected to work for all nonnegative integers, then 0 is a boundary test case.

Question 6

Trace messages

Answer 6

A message that is printed during a program run for debugging purposes.

Question 7

Test data

Answer 7

Input to test the program

Question 8

Test driven development (TDD)

Answer 8

A programming practice in which tests are written before actual code is written. The goal of the programmer then becomes that of ensuring that they write code such that all the tests pass.

Question 9

Assertion

Answer 9

A claim that a certain condition holds in a particular program location.

Question 10

Assert statement

Answer 10

A statement wherein the developer is asserting that something needs to be true. Usually, if the assertion fails, code execution is halted. In the context of JUnit testing, built-in assertion mechanisms are provided by the Assertions class.

Question 11

assertEquals

Answer 11

An inbuilt assertion used for asserting that the actual value of a variable (or the value returned by invoking a method) matches the expected value. Most unit tests will use this statement extensively.

Question 12

In a JUnit class, what is the annotation for a test?

Answer 12

@Test

Question 13

What is the proper syntax for a test that checks equality between a and b?

Answer 13

assertEquals(a, b);

* Note that additional parameters, such as an error message or a tolerance, can also be provided.

Question 14

Debugging

Answer 14

The process of trouble-shooting errors in your code

Question 15

What is the general process to debug code?

Answer 15

1. Place a breakpoint
2. Run the code in debug mode
3. Use the “Variables View” in Eclipse to review the changes to variable values as the code is executed to see where the results being returned are unexpected
4. Stop debugging when you think you’ve found the issue
5. Edit your code and change the breakpoint location, if needed

Question 16

Breakpoint

Answer 16

A point in the code where execution will be paused

Question 17

Stacktrace

Answer 17

The sequence of method calls that led to the current state

Question 18

Step-into

Answer 18

When paused at a breakpoint during the course of debugging, use Step-into to go into the method that is being invoked at that breakpoint.

Question 19

Step-over

Answer 19

Step-over is the same as step-into, except that when it reaches a call for another method, it will not step into the method.