Модуль: Как написать контрольный пример с использованием jUnit и Mockito - PullRequest
4 голосов
/ 18 мая 2011

Я очень новичок в Mockito, jUnit и TDD в целом, и я пытаюсь научиться правильно делать TDD.Мне нужны пары примеров, чтобы начать свой мозг.ТАК, пожалуйста, помогите мне

Так что у меня есть метод getNameInc(String dirPath, String filenName).Итак, имя файла, например, bankAccount.pdf, и если в этой папке нет имени файла bankAccount.pdf, верните bankAccountAA.pdf.Если существует один bankAccount.pdf, то return bankAccountBB.pdf increment равен AA-ZZ.Когда он достигает ZZ, он возвращается к AA.Я уже реализую логику этого метода.Как мне выполнить модульное тестирование этого метода, используя Mockiti и jUnit?

EDIT

Вот класс и методы, которые участвуют.

public class PProcessor{

    private final Map<Integer, String> incMap = new HashMap<Integer, String>();

    private String getNameInc(String dirPath, String filenName){
         String[] nameList = new File(dirPath).list(new FilenameFilter(){
            public boolean accept(File file, String name) {
                //only load pdf files
                return (name.toLowerCase().endsWith(".pdf"));
            }
        });
        //Return the number of occurance that a given file name appear
        //inside the output folder.
        int freq = 0;
        for(int i=0; i<nameList.length; i++){

            if(fileName.equals(nameList[i].substring(0, 8))){
                freq++;
            }
        }
        return incMap.get(freq);
    }

    private void generateIncHashMap(){
        incMap.put(new Integer(0), "AA");
        incMap.put(new Integer(1), "BB");
        incMap.put(new Integer(2), "CC");
        ...
    }
}

generateIncHashMap() будет вызываться в конструкторе для предварительной генерации хэш-карты

Ответы [ 2 ]

7 голосов
/ 18 мая 2011

Полагаю, вы пытаетесь проверить свой метод getNameInc (..). Когда вы вызываете его, он ищет файлы в указанном вами каталоге и на основе того, что находит, украшает имя, которое вы ему дали.

Чтобы сделать класс модульно-тестируемым, вы должны абстрагировать зависимость от файловой системы, чтобы в макете вы могли смоделировать любое содержимое каталога, какое захотите. Ваш класс примет экземпляр этого интерфейса как зависимость и вызовет его, чтобы узнать, что находится в каталоге. Когда вы используете класс в своей программе по-настоящему, вы предоставите реализацию этого интерфейса, которая делегирует вызовы файловой системы JDK. Когда вы выполните юнит-тестирование класса, вы предоставите Mockito макеты этого интерфейса.

Избегайте использования слишком большой логики в классе FilesystemImpl, поскольку вы не можете написать для него строгий модульный тест. Держите это очень простой оберткой вокруг файловой системы, чтобы все интеллектуальные вещи были в Yourclass, для которого вы будете писать множество модульных тестов.

public interface Filesystem {
    boolean contains(String dirpath, String filename);
}

public class FilesystemImpl {
    boolean contains(String dirpath, String filename) {
        // Make JDK calls to determine if the specified directory has the file.
        return ...
    }
}

public class Yourmainclass {
    public static void main(String[] args) {

         Filesystem f = new FilesystemImpl();
         Yourclass worker = new Yourclass(f);
         // do something with your worker
         // etc...
    }
}

public class Yourclass {
    private Filesystem filesystem;

    public Yourclass(Filesystem filesystem) {
        this.filesystem = filesystem;
    }

    String getNameInc(String dirpath, String filename) {
       ...
       if (filesystem.contains(dirpath, filename) {
          ...
       }
    }

}

public class YourclassTest {

   @Test
   public void testShouldAppendAAWhenFileExists() {
       Filesystem filesystem = Mockito.mock(Filesystem.class);
       when(filesystem.contains("/some/mock/path", "bankAccount.pdf").thenReturn(true);
       Yourclass worker = new Yourclass(filesystem);
       String actual = worker.getNameInc("/some/mock/path", "bankAccount.pdf");
       assertEquals("bankAccountAA.pdf", actual);
   }

   @Test
   public void testShouldNotAppendWhenFileDoesNotExist {
       Filesystem filesystem = Mockito.mock(Filesystem.class);
       when(filesystem.contains("/some/mock/path", "bankAccount.pdf").thenReturn(false);
       Yourclass worker = new Yourclass(filesystem);
       String actual = worker.getNameInc("/some/mock/path", "bankAccount.pdf");
       assertequals("bankAccount.pdf", actual);
   }
}

Поскольку между тестами существует много дубликатов, вы, вероятно, создадите метод настройки и сделаете некоторую работу там, а также создадите несколько переменных экземпляра для тестов:

    private static final String TEST_PATH = "/some/mock/path";
    private static final String TEST_FILENAME = "bankAccount.pdf";
    private Filesystem filesystem;
    private Yourclass worker;

    @Before
    public void setUp() {
        filesystem = Mockito.mock(Filesystem.class);
        worker = new Yourclass(filesystem);
    }

    @Test
   public void testShouldAppendAAWhenFileExists() {
       when(filesystem.contains(TEST_PATH, TEST_FILENAME).thenReturn(true);
       String actual = worker.getNameInc(TEST_PATH, TEST_FILENAME);
       assertEquals("bankAccountAA.pdf", actual);
   }

   etc...
5 голосов
/ 18 мая 2011

За то, что вы описали там, я не стал бы беспокоиться о Mockito, похоже, что там не над чем издеваться (потому что файловой системой легко манипулировать).

Я бы проверил ... - Что произойдет, если я позвоню getNameInc и не найдены подходящие файлы? - Что произойдет, если я позвоню getNameInc и там уже есть файлы AA-YY - Что произойдет, если я позвоню getNameInc и файл ZZ уже существует

Смысл TDD в том, что вы должны были уже написать эти тесты, а затем реализовать свой код, чтобы тесты прошли. Так что вы на самом деле не будете заниматься TDD, поскольку у вас уже есть код.

...