Почему вы пишете примеры кодов с помощью main () и выводите вместо тестов JUnit

Question

Я новичок в Stackoverflow и мне интересно, почему почти все пишут примеры кодов со статическим main () и выводят, как здесь, в первом ответе: какой-то уродливый main

от какого-то уродливого главного:

Но то, что вы опубликовали, похоже, это просто файл свойств. Попробуйте это:

import java.io.FileInputStream; 
import java.util.Properties; 

public class Main { 
    public static void main(String[] args) throws Exception { 
        Properties properties = new Properties(); 
        properties.load(new FileInputStream("test.properties")); 
        System.out.println(properties.getProperty("ReferenceDataLocation")); 
        System.out.println(properties.getProperty("LicenseKey")); 
        System.out.println(properties.getProperty("foo")); 
    } 
} 

который напечатает:

as
al
null

не было бы лучше написать его как JUnit Test? Это легче читать. Вы можете проверить результат только с помощью CTRL + C + CTRL-V + RunAs -> JUnit и посмотреть, что ожидается (или нет).

Я не прав с этой идеей?

Я бы написал так:

import static org.hamcrest.MatcherAssert.*;
import static org.hamcrest.Matchers.*;

import java.io.ByteArrayInputStream;
import java.util.Properties;

import org.junit.Test;


public class TestSomeInputStreamAsProperties {

    String someFileAsString =
    "ReferenceDataLocation = as\n"+
    "       \n" +
    "       \n" +
    "       ##############################################################################\n" +
    "       #\n" +
    "       #   LicenseKey\n" +
    "       #       Address Doctor License\n" +
    "       #\n" +
    "       ##############################################################################\n" +
    "       LicenseKey = al\n";



    @Test
    public void whenReadingFromSomeInputStreamWeShouldGetProperties() throws Exception {
        // Arrange
        Properties properties = new Properties(); 
        // Act
        properties.load(new ByteArrayInputStream(someFileAsString.getBytes())); 
        // Assert
        assertThat(properties.getProperty("ReferenceDataLocation"), is("as"));
        assertThat(properties.getProperty("LicenseKey"), is("al"));
        assertThat(properties.getProperty("foo"), is(nullValue()));
    }
}

Вопрос: зачем мне писать пример с main () и output? почему пользователи не пытаются сесть в поезд JUnit и начать писать тесты для проверки своего кода?

+

Другой вопрос: почему люди не публикуют свои проблемы как тесты JUnit?

Я немного разочарован.

РЕДАКТИРОВАТЬ : - не поймите меня неправильно. Это просто ожидания> реальность;) Я думаю, что stackoverflow по-прежнему отличный сайт, и я напишу здесь все свои проблемы и постараюсь помочь другим решить их. Я думал, что JUnit более распространен, и ваше сообщество будет признательно за решение проблем с JUnit.

Вместо этого я понимаю, что это никому не нужно. Разве вы тоже не будете разочарованы?

Answer 1

Не у всех есть JUnit, поэтому простая программа с main() с большей вероятностью будет работать где угодно.

Answer 2

Одно (вероятно, единственное) преимущество main() заключается в том, что это своего рода наименьший знаменатель - код должен быть понятным и воспроизводимым для всех, независимо от среды разработки и любимой среды тестирования (вы можете поспорить у людей был бы проприетарный - потому что они думают, что JUnit - дерьмо, или изворотливые корпоративные стандарты или что-то еще). Но если вы чувствуете себя более комфортно с JUnit, просто сделайте это - возможно, это понравится другим и начнут делать то же самое. «Это свободный мир ...»

Answer 3

не было бы лучше написать его как JUnit Test?

Не совсем.

Проще читать.

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

Вы можете проверить результат, просто нажав CTRL + C + CTRL-V + RunAs ->JUnit и посмотреть, что ожидается (или нет).

Только если вы используете IDE и у вас уже есть проект с этой инфраструктурой тестирования.

Пример кода должен продемонстрироватьодна конкретная вещь, а не вводить дополнительные понятия и зависимости.

Answer 4

Опытные разработчики программного обеспечения с открытым исходным кодом, имеющие опыт работы в нескольких громких проектах, знают, что лучший шанс получить исправление и интеграцию исправления - предоставить провальный модульный тест вместе с исправлением исправления.Но такие люди в основном отвечают на вопросы, а не спрашивают.

Таким образом, для ответчиков стоит задача продвигать хорошие методы опроса путем повышения / понижения вопросов и написания значимых комментариев.

Answer 5

Тест JUnit не является SSCCE , поскольку он не является автономным.

Answer 6

Хороший мальчик и хороший вопрос. Не делай так, как делают плохие парни! Люди, которые запускают уродливое main вместо тестов JUnit или TestNG - плохие парни! :)