Test-driven development practices and test-driven development

Test-driven development practices and test-driven development

I always think that I understand test-driven development. In fact, it is not the same thing to do and understand. I thought the code was very clear, and then I tried it to know that it was my illusion. This time, let's get rid of the automatic complementing feature of Eclipse. Let's get a real test-driven development.

Project Description: This is a simple project. The goal is to scan all files in specific formats on the disk and store their paths, you can use a program to quickly search for the file path and automatically locate the file.

User stories (simply written ):

1. Scan the disk, list all the files in the directory, and store the file information in a specific format to the disk.

2. Information about all files can be queried.

3. You can double-click the queried information to open the folder and locate the file.

Well, this is the first iteration target. The file format enumeration and storage to the disk can all be discussed later. In this case, we will focus on the story process, let's start designing and writing a test:

Design:

1. flat file storage. Each file is stored in the unit of action. different attributes are separated by ### and instantiated into the FileInfo class (story 1 ).

2. A flat file is called fileDB. The file reads the List in rows and writes the List in String format (story 1 ).

3. match a specific file with a regular expression (story 1 ).

4. the query condition is the file name. You can traverse the List to find whether the attribute complies with the contains rule (Story 2 ).

5. Open and locate the file with JNI explorer (Story 3 ).

Create a test:

The first concern here is the first one in the design.

Create a new Junit Test Case. I will call the Test class FileInfo. Therefore, this Test class is called FileInfoTest. It is in the same package path as FileInfo, but under different resource folder.

This Test Case should not pass the Test.

It turns out that it does not pass the test

Then, it should be initialized like this.

Compilation error! Of course, because the FileInfo class does not exist, let's create it.

After compilation, We need to output the field into a string with ### separator. the string is composed of FileName ### FileDir ### FilePath ### LastUpdate.

The test should be like this:

In order to solve these red bars, FileInfo has to become like this.

(Here there is a little far-fetched, that is, the source of the get method and the member variable is not "just passed the test", but the test was originally intended to lead out the member variable)

Now toString should be like this: a.txt ### c :\### c: \ a.txt ### 2016-01-01.

So the test should be like this (it takes time to write code! However, the process of participation in the design also increases, and the thinking and workload are increasing)

Of course, if the test fails, the two are not equal.

 

 

Of course, the reason is in toString

Modify the toString method of FileInfo:

Test passed!

At this point, I am thinking, if for some reason, I want to replace ### with @, then ### IN THE toString method should appear as a variable. However, because the code modified this time does not make any sense for passing the test and cannot add features, I will not do this. When will I do this? I will wait until the Code has a lot of features, And I Will refactor it and display the meaning of the test for my refactoring at this time.

Now we have finished Design 1. Let's start design 2. (Unfinished ......)