Comments 27
У вас на первой картинке база данных упала )
Извините за поправку, но в "… Основной принцип TDD состоит в том, чтобы напсать тесты ..." у Вас буква «и» в слове «написать» пропущена.
Пусть меня простят хабровчане, но не мог я пройти мимо заголовка «Автоматизированные тесты». Честно сказать, язык не поворачивается назвать тестами, то что предложил автор статьи:
describe('Truth', function () {
it('should be true', function () {
true.should.be.true
})
it('should not be false', function () {
true.should.not.be.false
})
})
и запустим его
$ ./node_modules/.bin/mocha --require should --reporter spec tests/test.js
Вполне естественно, что такой тест пройдет, так что заменим его на что-то неработающее
describe('foo variable', function () {
it('should equal bar', function () {
foo.should.equal('bar')
})
})
Если автор хотел показать знание TDD и умение писать тесты, то ему следует все таки в качестве примера приводить реальные тесты, пусть даже для тестового приложения. И у меня честно сказать сложилось впечатление, что автор не понимает что такое TDD. Почему я так подумал, а вот доводы: Во первых TDD не подразумевает написание «липовых» тестов, которые пройдут. Во вторых, не надо писать тест красной полосы только для того чтобы на фейковых данных показать что он не проходит. Это может не правильно трактоваться новичками, кто будет изучать TDD. И потом, не нужно подгонять тест под реализацию, реализация должна подчиняться тесту. Ибо тест — это контракт.
describe('Truth', function () {
it('should be true', function () {
true.should.be.true
})
it('should not be false', function () {
true.should.not.be.false
})
})
и запустим его
$ ./node_modules/.bin/mocha --require should --reporter spec tests/test.js
Вполне естественно, что такой тест пройдет, так что заменим его на что-то неработающее
describe('foo variable', function () {
it('should equal bar', function () {
foo.should.equal('bar')
})
})
Если автор хотел показать знание TDD и умение писать тесты, то ему следует все таки в качестве примера приводить реальные тесты, пусть даже для тестового приложения. И у меня честно сказать сложилось впечатление, что автор не понимает что такое TDD. Почему я так подумал, а вот доводы: Во первых TDD не подразумевает написание «липовых» тестов, которые пройдут. Во вторых, не надо писать тест красной полосы только для того чтобы на фейковых данных показать что он не проходит. Это может не правильно трактоваться новичками, кто будет изучать TDD. И потом, не нужно подгонять тест под реализацию, реализация должна подчиняться тесту. Ибо тест — это контракт.
Внимательно читали?
Я на самом деле предполагал, что кого-то может зацепить такой пример, так что подумаю еще как подшлифовать это место, но все таки стоит целиком текст читать :) В следующей главе будем писать первый контроллер, там уже реальные тесты будут, не беспокойтесь.
PS: Автор хорошо понимает что такое TDD, не беспокойтесь.
Основной принцип TDD состоит в том, чтобы написать тесты до того как написан код, таким образом мы можем убедиться в том, что тесты действительно что-то тестируют, а не просто запускают код на выполнение и делают проверки в стиле true.should.be.true.
Я на самом деле предполагал, что кого-то может зацепить такой пример, так что подумаю еще как подшлифовать это место, но все таки стоит целиком текст читать :) В следующей главе будем писать первый контроллер, там уже реальные тесты будут, не беспокойтесь.
PS: Автор хорошо понимает что такое TDD, не беспокойтесь.
Я внимательно читал :) Извиняюсь, если задел своим комментарием, но Вы написали первый и единственные тест после того как указали реализацию app.js и server.js. А должны были для начала написать тест красной полосы именно для проверки GET запроса. Вместо этого вы пишите якобы тесты «true есть true» и «foo не равно bar» — это все к вашему тестовому проекту ну никак не относится. Так что извините, но судя по статье я не очень верю в то, что Вы действительно понимаете что такое TDD. Ничего личного, лишь моя объективная оценка.
Примеры таких тестов я привел скорее для проверки того, что фреймворки корректно установились, и хелло ворлд не имеет отношения к тому приложению, которое мы будем писать, вы же заметили что перед коммитом я предложил вообще удалить файл с тестом? Это просто подготовка фреймворков а не процесс написания приложения. Неужели вы думаете, что было бы лучше с первых шагов заставлять человека писать hello world с проверкой переменных окружения прятать код в отдельную директорию и делать загрузчик чтобы нормально потом jscoverage интегрировать? Надо постепенно в курс дела вводить, сначала просто дать возможность пощупать фреймворки. На днях выложу 3-ю главу, там уже начнем само приложение писать, все будет ок с тестами. Я на самом деле понимаю желание придраться к этому моменту, мне и самому глаз немного режет, но в контексте всей главы это явно не тянет на основания для того чтобы заявлять «Вы не понимаете что такое TDD».
Ну извините, если я Вас обидел, честно сказать не хотел. Мне просто всегда говорили, если что то хочешь показать, рассказать продумай все! (совсем все продумать конечно не получается, но минимализировать кол-во ошибок можно). Т.е. Вы понимали, что все таки, то что Вы выложили не совсем корректно, но однако не хотите понять, то что даже для того чтобы пощупать фреймворки, не надо выкладывать откровенно пустой и ничему не учащий код. Я не говорю что Вам надо сразу все показывать, но если Вы решили показать как писать тесты, то лучше бы взяли бы какой нибудь простенький класс на JavaScript и тут показали бы преимущества TDD, но не на тех тестах, которые Вы привели.
============================================================================================
И потом я ничего не услышал в Вашем комментарии по поводу того факта, что Вы указали реализацию app.js и server.js, а потом показали тест на GET запрос (Это явно не в стиле TDD).
============================================================================================
Посмотрите подкасты по TDD и Вы увидите, авторы не делают себе поблажек или осечек или приписки («не хочется сразу все показывать»), они стараются показать пример другим, чтобы людям было приятно посмотреть. И чтобы не было таких вот замечаний по поводу корректности представленного.
По этому, раз уж заговорили про TDD будьте добры в тексте, показывать шаги: RED, GREEN, REFACTOR касаемо тестируемой сущности (у Вас к сожалению нет ничего такого по отношению к тестированию того же GET запроса на главную страницу. Я вижу единственный тест.).
А иначе это просто можно назвать «показ того как можно тест написать ради забавы (исследовани возможностей фреймворка)»
Ну в общем то вывод делать Вам :) Я лишь высказал свое мнение. :) Спасибо что выслушали :)
============================================================================================
И потом я ничего не услышал в Вашем комментарии по поводу того факта, что Вы указали реализацию app.js и server.js, а потом показали тест на GET запрос (Это явно не в стиле TDD).
============================================================================================
Посмотрите подкасты по TDD и Вы увидите, авторы не делают себе поблажек или осечек или приписки («не хочется сразу все показывать»), они стараются показать пример другим, чтобы людям было приятно посмотреть. И чтобы не было таких вот замечаний по поводу корректности представленного.
По этому, раз уж заговорили про TDD будьте добры в тексте, показывать шаги: RED, GREEN, REFACTOR касаемо тестируемой сущности (у Вас к сожалению нет ничего такого по отношению к тестированию того же GET запроса на главную страницу. Я вижу единственный тест.).
А иначе это просто можно назвать «показ того как можно тест написать ради забавы (исследовани возможностей фреймворка)»
Ну в общем то вывод делать Вам :) Я лишь высказал свое мнение. :) Спасибо что выслушали :)
«показ того как можно тест написать ради забавы (исследовани возможностей фреймворка)»
Так и есть, начнем писать реальное приложение будут и тесты реальные.
Вот ссылочка на недописаную 3-ю главу github.com/DavidKlassen/node-tutorial/wiki/Web-%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0-%D0%BD%D0%B0-node.js-%D0%B8-express#wiki-3.1 можете заранее свое мнение высказать, а можете даже форкнуть и поучаствовать в написании, буду признателен.
Я впервые столкнулся с проблемой TDD как раз в виде Rails Tutorial. Так вот я хочу немного защитить автора. Мне как новичку довольно сложно было (да и есть) стразу писать «настоящие», сложные тесты. Я думаю введение просто необходимо. Как минимум, что бы проверить, что тесты и фреймворки сами по себе работают!
Никто не говорил про сложные тесты :) Я лишь говорил про реальные тесты. Да собственно я и не нападал на автора, лишь выразил свое мнение. Я вижу что, статья автора хорошая и ничего не имею ни против автора ни против статьи :) Я лишь указал на недостатки, на которых я посчитал нужным заострить внимание :) Ваше мнение я тоже уважаю :).
— Теперь все же хочу заострить ваше внимание на проверке работоспособности тестовых (да и любых фреймворков), для их проверки необходимо запускать тесты идущие в репозитории с фреймворком, к примеру у supertest есть тесты проверяющие корректность работы фреймворка. Потому я бы очень хотел, чтобы авторы таких статей все же более правильнее относились к тому, как преподносить информацию. У should.js тоже есть свои тесты, потому что эти фреймворки пишут достаточно грамотные и активные люди.
Потому будьте профессионалами, не забывайте про назначение тех или иных средств. Не стройте велосипеды с откровенно плохими «проверками» работоспособности. :)
И опять же судить, о том прав я или нет — Вам! Я не могу что то навязать, я лишь советую.
Оссу!
— Теперь все же хочу заострить ваше внимание на проверке работоспособности тестовых (да и любых фреймворков), для их проверки необходимо запускать тесты идущие в репозитории с фреймворком, к примеру у supertest есть тесты проверяющие корректность работы фреймворка. Потому я бы очень хотел, чтобы авторы таких статей все же более правильнее относились к тому, как преподносить информацию. У should.js тоже есть свои тесты, потому что эти фреймворки пишут достаточно грамотные и активные люди.
Потому будьте профессионалами, не забывайте про назначение тех или иных средств. Не стройте велосипеды с откровенно плохими «проверками» работоспособности. :)
И опять же судить, о том прав я или нет — Вам! Я не могу что то навязать, я лишь советую.
Оссу!
Божественно!
touch package.json печалит команду npm init.GitHub для node.js проектов при выборе нужной опции автоматически создаёт такой .gitignore.
Это не совсем тот .gitignore который нужен, он заточен под нодовские либы, а у нас к примеру инструментированный код лежит в app-cov, а не в lib-cov. Думаю те кто серьезно займутся разработкой на ноде и сами со временем все плюшки обнаружат, у меня скорее цель заинтересовать.
> а у нас к примеру инструментированный код лежит в app-cov, а не в lib-cov
А что мешает использовать github'овский .gitignore +
А что мешает использовать github'овский .gitignore +
echo 'app-cov' >> .gitignore
echo 'coverage.html' >> .gitignore
Ничего не мешает, это уже незначительные нюансы, только не уверен, что таким мелочам место в туториале.
Ну просто получается, что вы без предупреждения даёте напутствие пользователям изобретать велосипеды, хотя зачастую у них и покрытие будет лежать в lib-cov, и синтаксис package.json их устроит, и файлы будут лежать в /test.
Ну это не велосипеды, так, самокатики. Я же даю ссылки на документацию, там все это написано, а пока человек еще не въехал, мне кажется лучше просто дать набор инструкций и возможность потрогать получающееся приложение, если вдруг заинтересуется — в мелочах потом сам разберется. На самом деле непросто найти оптимальный подход в изложению материала, я в поиске, так что критика приветствуется :)
Библиотеки для тестов можно было установить еще проще.
npm install mocha should supertest --save-dev
1) mocha по умолчанию командой
Если у вас директория называется tests, достаточно было команды
2) чем вас не устроили
./node_modules/.bin/mocha запускает тесты test/*.js.Если у вас директория называется tests, достаточно было команды
./node_modules/.bin/mocha tests2) чем вас не устроили
npm test и npm run-script ...?1. integration и unit тесты в разных поддиректориях будут в дальнейшем, а mocha рекурсивно по директориям не бегает.
2. Дело вкуса на самом деле. Во-первых мне нравится стиль в котором TJ свои проекты оформляет, во вторых тасков много, а писать
2. Дело вкуса на самом деле. Во-первых мне нравится стиль в котором TJ свои проекты оформляет, во вторых тасков много, а писать
npm run-script text-cov дольше, чем make test-cov, да и package.json засирается. Makefile лучше для этих целей подходит, имхо.1. --recursive
2. Да, наверное действительно дело вкуса. И, возможно, я уже привык писать run-script :)
2. Да, наверное действительно дело вкуса. И, возможно, я уже привык писать run-script :)
1. Вот за это спасибо :) Так удобнее — факт!
Я на самом деле когда искал вариант рекурсивного выполнения тестов наткнулся на issue в репе mocha где tj сам предложил вариант использующийся в мейкфайле
Я на самом деле когда искал вариант рекурсивного выполнения тестов наткнулся на issue в репе mocha где tj сам предложил вариант использующийся в мейкфайле
github.com/visionmedia/mocha/issues/106 но это год назад было, видимо добавил опцию
Sign up to leave a comment.
Web разработка на node.js и express. Глава 2 — тестирование приложения