Pull to refresh

Comments 15

UFO just landed and posted this here
Спасибо за первый коммент! Это правда вечный спор :)

У нас лучшие разработчики, и именно в этом моё везение.

Я думаю, что соль тестировщика в мышлении: понимать, как продукт используется, проверять все важные случаи и находить интересное. А какие инструменты использовал — вторично. Как математика инструмент для физики. Простите :)

Ценно, когда человек легко осваивает новые инструменты.
Свой фреймворк конечно хорошо, если он не едет дальше по другим отделам вдохновленных вашим успехом. Вот тут начинается головная боль и у тех кто использует, и у тех кто поддерживает

Когда-то фреймворки, ныне существующие на рынке — тоже были чьим-то самописным фреймворком :)
Если автор оказался хорош, то это используется многими.
Если плох, то это становится "кривой велосипед"

Все правильно. Насколько велосипед удачен можно сказать только после того как его опробывали не только создатели
Это интересно.
У нас много специфики, но общую часть можно выделить для тех, кто регулярно актуализирует тесты в текстовом файле и хочет добавлять тесты с ссылкой на задачу.
Есть коллеги, кто не решил ещё эти задачи в своих тестах?
На самом деле даже если и решили все, и вдруг появится/заопенсорсится новый инструмент/способ — всегда найдутся те, кто попробует хотя бы из любопытства… И если этот инструмент решит задачу или сделает решение проще… Молва пойдет :) testng тоже появился после junit, и ничего, нашел нишу/отобрал свой кусок. И потом подготовка проекта к выкладыванию на всеобщее обозрение это всегда стерсс и интересно. Потому что понимание проекта и его применимости сразу на несколько уровней улучшается :)

Спасибо за интересную статью, ваш опыт очень радует и снова подтверждает, что построение удобного CI возможно и улучшает качество продукта

Так вроде же у вас не тестовый фреймворк с нуля, а очень умная параметризация поверх TestNG.


И это хорошо: берём готовое и допиливаем под себя

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

Что мешает список кейсов положить в версионное хранилище вместе с кодом и сливать изменения в списке в общий список кейсов тоже вместе с исправленным кодом? Тогда у вас подобных проблем не будет.
Такой опыт тоже был. Но процесс с одним файлом оказался проще, телодвижений меньше, чеклисты короче.
По моему, вы про какой-то другой вариант говорите. Я про файл со списком — почему он не там же, где код?
Эх, мне бы такой API, как у ТС, я б автоматизировал.
Ну не так чтобы уж прямо совсем уж свой фреймворк получился. Это больше вдумчивая модернизация имеющегося для ваших нужд. Вам повезло, что есть люди которые в это умеют, и знают как сделать так, чтобы было хорошо. И еще у них было/есть на это время. Редко когда (никогда) на тестирование выделяют достаточно ресурсов.

Так-то unittest движки очень не удобны для функциональных тестов. Несмотря на то, что они уже давно умеют в DDT из коробки, и умеют брать тестовые данные из разных сорсов, вплоть до БД. Но все же, неудобно феноменально. Именно поэтому появляются Cucuber и Robot Framewok.
Sign up to leave a comment.