Lesson 1. Getting Started

1장에서 배울 것은 :

  • 간단한 Java class 만들기
  • Java class를 가지고 노는 test class 만들기
  • JUnit famework 사용하기
  • 생성자에 대해 배우기
  • 위에서 작성한 code 리팩토링하기.


Test-driven development means that you will write tests for virtually every bit of code. It also means that you will write the tests first. The tests are a means of specifying what the code needs to do. After writing the corresponding code, the tests are run to ensure that the code does what the tests specify.

The production classes you build should know nothing about the tests written for them.


You start by building only high-level designs, not highly detailed specifications. You will continually refine the design as you understand more about the customer needs. You will also update the design as you discover what works well and what doesn’t work well in the Java code that you build. The power of object-oriented development can allow you this flexibility, the ability to quickly adapt your design to changing conditions.

A Simple Test

You must designate the class as public in order for the testing framework JUnit to recognize it.

The classpath is a list of locations separated by semicolons under Windows or colons under Unix. You supply the classpath to both the compiler and the Java VM. A location can be either a JAR file (which contains compiled class files by definition) or a directory that contains compiled class files.

ex) javac -classpath c:junit3.8.1junit.jar StudentTest.java(the abbreviated keyword -cp.)


Not only does the Java compiler need to know where the JUnit classes are, but the Java VM also needs to be able to find these classes at runtime so it can load them up as needed.

java -cp .;c:junit3.8.1junit.jar junit.awtui.TestRunner StudentTest

Adding a Test

public class StudentTest extends junit.framework.TestCase {
public void testCreate() {
  • the method must be declared public,

  • the method must return void (nothing),

  • the name of the method must start with the word test, in lowercase letters, and

  • the method cannot take any arguments ().

Creating a Student

new Student(“Jane Doe”);

You terminate each statement with a semicolon (;).

You place the new keyword before the name of the class to instantiate.

String literals represent object instances of the predefined Java class java.lang.String.

When the Java VM executes the new operator in this statement, it allocates an area in memory to store a representation of the Student object. The VM uses information in the Student class definition to determine just how much memory to allocate.

Creating the Student Class

class Student {}


A constructor looks a lot like a method. It can contain any number of statements and can take any number of arguments like a method. However, you must always name a constructor the same as the class in which it is defined. Also, you never provide a return value for a constructor, not even void.

Local Variables

Student student = new Student(“Jane Doe”);

When the Java VM executes this statement, it executes the code to the right-hand side of the assignment operator (=) first, creating a Student object in memory. The VM takes note of the actual memory address where it places the new Student object. Subsequently, the VM assigns this address to a reference on the left-hand side, or first half, of the statement.

Returning a Value from a Method

String studentName = student.getName();

you are sending a message to the Student object, using the student reference assigned to in the previous statement.

String getName() { }

This getName method specifies instead a return type of String.

return “”;

The return statement here returns an empty String objecta String with nothing in it.


The first step is to eliminate the unnecessary local variables.
The second step: It is considered poor programming practice to embed String literals throughout your code. One reason is that the code can be difficult to follow if it is not clear what each String literal represents.


There are two ways to ensure that the value of the formal parameter is assigned to the field:
The first approach means you must rename either the parameter or the field.
The second approach for disambiguating the two is to use the same name for both, but where necessary refer to the field by prefixing it with the Java keyword this.