ШТА? acceptance testing - последний этап тестирования, который завязан на конечную реализацию проги, делается при непосредственном участии заказчика и я в упор не представляю, как его можно автоматизировать какими-либо инструментами. расскажи подробнее, о чем ты?

man BDD.
Пишешь сценарии. Типа, зайти туда, нажать на такую-то ссылку, если результат такой, заполнить форму, отправить, взять такую-то информацию и если... то... А потом пишешь код, чтобы тесты заработали. Тесты периодически сами запускаются во всех возможных браузерах, дабы быть увереным, что усё хорошо и т.п.

Демо инструмента acceptance, unit и coverage testing'а (всё в одном флаконе) для Meteor'а здесь: https://www.youtube.com/watch?v=ESVRDEY-QSk Классная вещь, если б ещё не глючная.

P.S.: Нашёл selenium и драйвер под go, но оно как-то не очень впечатлило.

Баранцева на тебя нет.

man QA. BDD никак не отменяет того, что acceptance testing делается в финальной стадии проекта, один раз и при _обязательном_ участии заказчика/product owner'а. смысла автоматизировать приемочное тестирование - никакого. абсолютно. даже если вокруг сплошные огурцы и bdd с табличками.

тебе нужен фреймворк для написания автоматизированных тестов, работающий с go? так и говори. хотя смысла в нем никакого, разве что команды qa у вас нет, и разработчик сам пишет для себя тесты. если так - пиши хоть в экселе, результату это не сильно повредит. если же qa есть - то на go достаточно писать только unit тесты, а все остальное - забота тестировщика, который не дурак, и выберет инструмент и язык который ему удобнее.

и да, jfyi: BDD - это https://en.wikipedia.org/wiki/Behavior-driven_development , а не непонятно откуда свалившийся https://en.wikipedia.org/wiki/Business-driven_development

а твои acceptance test - на самом деле обычный баззворд, для того чтобы отделить автотесты, написанные на cucumber'е от таких же автотестов на селениуме. ничего общего с адекватным пониманием приемочного тестирования не имеющие

По твоей же ссылке:

Acceptance tests should be written using the standard agile framework of a User story: «As a [role] I want [feature] so that [benefit]».

the practice of BDD does assume the use of specialized software tools to support the development process.

Так что выглядит оно как то самое.

Кроме того:

Acceptance testing is a term used in agile software development methodologies, particularly Extreme Programming, referring to the functional testing of a user story by the software development team during the implementation phase.

(«Introduction to Acceptance/Customer Tests as Requirements Artifacts». agilemodeling.com. Agile Modeling. Retrieved 9 December 2013)

Как то так.

ага,

Acceptance tests are also used as regression tests prior to a production release. A user story is not considered complete until it has passed its acceptance tests. This means that new acceptance tests must be created for each iteration or the development team will report zero progress.

конечно же никакой это не баззворд на ровном месте, никаким образом не пересекается с регрессионным тестированием и никаким образом не мешает адекватно воспринимать термин приемочное тестирование из теории qa

а давай я тебе расскажу как выглядит это на практике: есть сверхидея, мол po опишет нам все требования к функциональности в виде теста на кукумбере или еще каком похожем фреймворке, не ошибется, ничего не пропустит, мы назовем это acceptance test'ами, и будем радоваться до тех пор, пока приемочное тестирование, сделанное на уже готовом функционале не обломает нам всю малину, после чего мы вернемся к старому-доброму test first, при котором тесты будут писаться в том же самом виде «зайти туда, нажать на такую-то ссылку, если результат такой, заполнить форму, отправить, взять такую-то информацию и если... то... », только делать это будет не заказчик, а технически хоть сколько-нибудь грамотный qa/dev.
если тебе все-таки нужен фреймворк для bdd - бери любой, тот же cucumber подойдет. все равно в итоге будет шизофренический dsl

конечно же никакой это не баззворд на ровном месте

Acceptance testing is an inherent part of custom systems development. It takes place after release testing. It involves a customer formally testing a system to decide whether or not it should be accepted from the system developer. Acceptance implies that payment should be made for the system.

In agile methods, such as XP, acceptance testing has a rather different meaning. In principle, it shares the notion that users should decide whether or not the system is acceptable. However, in XP, the user is part of the development team (i.e., he or she is an alpha tester) and provides the system requirements in terms of user stories.

He or she is also responsible for defining the tests, which decide whether or not the developed software supports the user story. The tests are automated and development does not proceed until the story acceptance tests have passed. There is, therefore, no separate acceptance testing activity.

Software Engineering. Ian Sommerville. ISBN 10: 0137035152 / 0-13-703515-2. ISBN 13: 9780137035151. Addison-Wesley (2010)

There is, therefore, no separate acceptance testing activity.

в книжках по xp - да, нет. и в сферическом xp в вакууме нет. а в реальном есть. и в реальном мире the user не ограничивается тем, что он is part of the development team, а хочет побыть и po и в итоге реальном мире получается так, как я описал выше. можешь, конечно, поиграться в идеальный мир, но смысла в этом я не вижу.

чсх, твое кидание оторванными от жизни цитатами не приблизило тебя ни на сантиметр к решению твоей задачи. нужен фреймворк для bdd? cucumber. не умеешь в ruby - cucumber.js. но меня все равно не покидает ощущение что ты засрал себе голову кучей баззвордов без понимания того, как и что ты хочешь тестировать. у тебя уже написаны product owner'ом истории? или ты считаешь что ты сам их напишешь для своего же продукта? или ты вообще команда из одного человека, который зачем-то сам для себя нагородит dsl для bdd, которым ему будет конечно же удобнее пользоваться чем нормальным фреймворком для go?

а давай я тебе расскажу как выглядит это на практике

Давай уж детали, на чьей практике (если ГС «клиентам» загонять, конечно, нужна только приёмка, чтобы расчёт получить и с концами), пруфы.

оторванными от жизни цитатами

Reference is needed.

ГС «клиентам» загонять, конечно, нужна только приёмка, чтобы расчёт получить и с концами

забыл добавить про написанные на убогоньком недоязычке.

опыта тестирования у меня много и разного, меряться кто на стенку выше писает - я не буду.

если ты считаешь что acceptance testing - нормальное обозначение для регрессионного и функционального тестирования просто потому что _у_нас_тут_agile_и_xp_ при довольно очевидно определенном IEEE термине acceptance testing - считай. но если ты хочешь чтобы на твои вопросы давали ответы и чтобы тебя понимали - постарайся говорить с людьми на общепринятом языке, а не на помеси баззвордов и откровенно маркетоидной чуши.

reference? на оторванность от жизни цитат про то, как у всех xp и все работает на одном bdd и unit тестах? тут знаешь, гораздо актуальнее reference на хоть один успешный проект, сделанный реальными людьми по сферическим в вакууме заветам xp.

нормальное обозначение для регрессионного и функционального тестирования

Экак ты разные категории в один ряд поставил.

Да всё ясно, свою позицию ты обозначил: ненужно.

при довольно очевидно определенном IEEE термине acceptance testing

Ссылки тоже не нужны.

Экак ты разные категории в один ряд поставил.

караул какие разные. но тебе виднее, да. особенно после замены двух _разных_категорий_ одним идиотским термином

Да всё ясно, свою позицию ты обозначил: ненужно.

ненужно - это про жонглирование терминами, в которых ты вообще нихрена не понимаешь. bdd и xp пусть и обладают сомнительной нужностью, но иногда работают, если не относиться к ним как к серебрянной пуле

Ссылки тоже не нужны.

IEEE 610. скопипастить тебе бумажный вариант, или погуглишь электронный?

Да ты упорот.

про жонглирование терминами, в которых ты вообще нихрена не понимаешь

Проекция она такая. После твоего «регрессионного и функционального» можешь ничего больше не говорить.

IEEE 610. скопипастить тебе бумажный вариант, или погуглишь электронный?

Это тот, который 1990 года, а в 2002 признан устаревшим? Так можешь подтереться своим бумажным вариантом, печку растопить, на крайний случай.

Это тот, который 1990 года, а в 2002 признан устаревшим?

ага, настолько устаревшим, что в документации gasq 2011 года термин acceptance testing ни капли не изменился. но да, если у тебя под рукой случайно завалялся ieee 24765 - уешь меня свежей цитатой

После твоего «регрессионного и функционального» можешь ничего больше не говорить.

я все-таки скажу, можно? ну не то, чтобы скажу, процитирую твои же цитаты: «referring to the functional testing of a user story» ... «also used as regression tests»