[Twisted Web] Unit-тестирование HTML-вывода

Хочешь убедиться, что сайт выглядит хорошо, но при этом не завязваться на дизайн? Интересно. Ну тогда загружай весь HTML, беги по элементам и проверяй, что все нужные хотя бы существуют.

Я не хочу убеждаться, что сайт выглядит хорошо, я хочу убедиться, что он выглядит вообще (то есть не падает с ошибкой 500) и содержит нужную информацию.

Как я уже сказал, зависеть от структуры тэгов не хотелось бы.

Unit-тестирование HTML-вывода

Учи матчасть. Это называется уже функциональные тесты. Посмотри в сторону Selenium IDE, Selenium RC Server.

Для нормальных регрессионных тестов с возвращаемым тексом по-любому удобнее всего регэкспы.

Если джаву/JUnit не знаешь (там надо написать функцию с URLConnection, вытаскивающую результат, возвращённый сайтом как стринг, либо понаписать коллбеки - чтобы иметь в многих юнит-тестах по одной похожей короткой строке) - то можно воспользоваться более простым вариантом: Netcat или wget, пайпить на sed (с регуларными выражениями) и иметь шелл-скрипт с большим количеством разных тестов. Но тогда надо шелл-скриптинг знать (знать как писать функциям и передавать им итд). Либо Перл. Наверное, то же самое ещё легче в том же Питоне.

>завязывать тесты на дизайн

Ориентироваться по id? Если, конечно, нет привычки их постоянно менять.

Просто для иллюстрации (может быть будет полезно)...
мои юнит тесты на джаве обычно выглядят так (утилити-функции написаны так - чтобы сами юнит тесты были предельно короткими, ведь их надо эффективно менеджить, менять итд):

для парсера (функции не фонтан, не так наглядно как в следующем примере):

      assertEquals(PASAParser.parse2RE(«8* (excluding 8~995)», false),
         «8(?!.995).*»);
      
      assertEquals(PASAParser.parse2RE(«8* (except 8~995), 7*», false),
         «8(?!.995).*|7.*»);   
      
      assertEquals(PASAParser.parse2RE(«7*, 8* (excluding 8~995, 8~996)», false),
         «7.*|8(?!.995|.996).*»);
      
      assertEquals(PASAParser.parse2RE(«7* (excluding 735107030, 7~550,7~551)», false),
         «7(?!35107030|.550|.551).*»);

      assertEquals(PASAParser.parse2RE(«71* (excluding 715354030), 81*», false),
         «71(?!5354030).*|81.*»);
      
      assertEquals(PASAParser.parse2RE(«F465* (Not F46599)», true),
         «F465(?!99).*»);
      
      assertEquals(PASAParser.parse2RE(«7~5 (excluding 725407640, 725407650, 725407840), 7~551*», false),
         «7(?!25407640|25407650|25407840).5.*|7.551.*»);
      
      assertEquals(PASAParser.parse2RE(«7~4*, 7~5*(excluding 735107030, » +
         «7~550*, 7~551*, 7~555* , 7~558*, 7~560*, 7~565*, 7~5407640, 7~5407650, » +
         «7~5407840,7~570*)», false),
            «7.4.*|7(?!35107030|.550|.551|.555|.558|.560|.565|.5407640|.5407650|.5407840|.570).5.*»);      
      
      assertEquals(PASAParser.parse2RE(«7~5* (excluding 7~5407640, »+
            «7~5407650, 7~5407840, 7~5407850, 7~575, 7~554*)», false),
         «7.5(?!407640|407650|407840|407850|75|54).*»);

........... итд

для проверки сиквелом всех сумм (в твоём случае будут сравнения с регэкспами, а не числами):

      //no submissions with 20 - for the same (year, period, source, submitter):
      assertTrue(«0».equals(
            DBUtil.getScalar(
               «select count(*) from » +
                  Config.getDBSchema() + «re_file_submission » +
               «where file_submission_id <> » + submissionId +
               " and gre_data_source_code = 'asdg'" +
               " and reporting_year_code = '2006/2007'" +
               " and reporting_period_code='YE'" +
               " and report_status_type_code='20'" +
               " and gre_submitter_number='0014'")));
      
      //inserted record has correct fields/attributes:
      assertTrue(«1».equals(
            DBUtil.getScalar(
               «select count(*) from » +
                  Config.getDBSchema() + «re_file_submission » +
               «where file_submission_id = » + submissionId +
               " and gre_data_source_code = 'asdg'" +
               " and reporting_year_code = '2006/2007'" +
               " and reporting_period_code='YE'" +
               " and report_status_type_code='20'" +
               " and gre_submitter_number='1231'")));       
      
      //exactly 1590 records been inserted into RE_OTHER_SUBMISSION:
      assertTrue(«1590».equals(
            DBUtil.getScalar(
               «select count(*) from » +
                  Config.getDBSchema() + «re_other_submission » +
               «where file_submission_id=» + submissionId +
               " and DATA_SOURCE_CODE='АСДГЙК'"))); //check also the source   

........... итд

и таких одинаковых строк (с регэкспами либо сиквелом) - тысячи. Т.е. регэксп и SQL являются удобными промежуточными языками в юнит-тестах. И запросы с аггрегатными функциями покрывают возможные ошибки достаточно плотно.

Как то так.

Если симметрия не так видна - поясняю (тысячи однотипных строк - не только нагляднее, можно даже генерить или как минимум поддерживать сорс унит-тестов мета-скриптом).
Есть ввод (параметры, которые меняются тысячи раз) и есть ожидаемые выводы. Их надо иметь в максимально простом, коротком и наглядном виде, в виде скрипта, списка итд. Т.е. компактный язык типа регэкспа или SQL позволяет разрулить сложность в юнит тестах и сделать automation легко поддерживаемой.
Я бы в твоём конкретном случае всё же наверное делал на шелле (links -y, wget, nc etc | sed), а не на JUnit.

http://seleniumhq.org/projects/remote-control/

Есть функциональные, есть Unti-тесты. Или ты не видел Unit-тестов для GUI?

А вот это интересно, спасибо