Comments 19
Последние версии официального драйвера во всем превосходят довольно отсталый Mongoose.
Интересуют следующие пункты:
1) Поддержка промисов
2) Валидация полей
3) Псевдо join'ы (Аналог populate)
4) Хуки
1) Да
2) Нет надобности и это антипаттерн. Данные надо проверять самостоятельно с помощью JSON Schema.
Это добавляет гибкости при работе. К примеру, данные можно отбросить на входе, а не перед самой записью в базу данных.
Таким образом, весь код которые работал до этого не подвергается риску работы с invalid objects.
3) Нету как и в самой базе данных :) Data Models > Data Model Reference > Database References
За пару лет работы с нодой и монгой понадобилось сделать ссылку ровно 2 раза.
4) Не знаю что это.
В целом, работа с нативным драйвером после Mongoose это танец на радуге удобства и изобилия.
А еще хорошо бы не использовать Mocha.
- Как я понял сделать вложенные утверждения не получится
примерНапример «создание книги»:
1. книга создается успешно
2. при отсутствии поля N выдается ошибка
3. при отсутствии заголовка H возвращается 403
Для каждого такого описание придется делать отдельный файл, чтобы получить соответствующий вывод.
Mocha же дает структурированный вывод + tape формат можно подключить с помощью плагина
- Общая настройка фикстур бывает нужна при негативном или альтернативном тестировании, когда есть набор данных и он заполняется перед группой тестов и после нее гасится
Это то, что на первый взгяд вызвало сомнения в удобстве tape.
Хотя все наверно зависит от выработанного workflow/структуры проекта
Нет, можно вкладывать сколько угодно, если хочется, в том числе и так, как вы написали, у меня есть пример. Но, сказать по правде, «плоские» тесты проще писать и поддерживать в долгой перспективе.
Вложенность ведет к тому, что начинаешь опираться на состояние, оставшееся после предыдущего теста.
let express = require('express');
Ммм. А какой смысл там использовать let, а не const? Включите prefer-const везде =).
Объясните мне, пожалуйста, неужели приятно использовать chai?
Вот эта вот вся магия типа req.should.have.status(200), её же писать умучаешься!
Для себя решил что всегда в качестве assert-библиотеки буду использовать power-assert: assert(req.status === 200) — всё чётко и понятно, писать проще, читать легче, а power-assert даёт понятное описание ошибки.
Может быть я сильно заблуждаюсь а chai является верхом инженерной мысли?
Ну в принципе const assert = require('chai').assert;.
А это все should.have идет из BDD, когда решили, что лучше тестировать поведение программы и что для этого почему-то нужно соорудить свой якобы человекопонятный DSL.
chai дает даёт ассерты описаные языком близким к натуральному. к тому у chai есть удобный chain механизм.
Например, мы ждем от api в ответ json c какой-то конкретной ошибкой. Sould синтаксис дает понимание что мы хотим
req.body.should.be.an.Object().which.has.property('error','error text')Ваш подход больше подходит тем, кто сам себе и программист и тестироващик. И это все-таки ближе к идеям tdd, так как не описывает поведение, а проверяет код.
A bdd — это по сути переложение тех.задания тестировщиком с учетом различных use-case. Оно и код проверяет и поведение описывает.
Chain механизм вполне работает и со стандартными && операторами, ваш пример можно записать так:
assert(typeof req.body === "object" && "error text" === req.body.error)
Ну или два assert написать, будет ещё читаемее. Писать это несравненно легче.
Я действительно пробовал писать проверки в стиле should/expect, очень бесило то, что постоянно приходится лазить в документацию на первых этапах.
Описание условий формальным языком работало бы, если весь тест им описывался. А по факту — формальным языком описываются только ассерты, а код теста всё равно на обычном ЯП (в нашем случае javascript). В итоге тестировщику проще нучиться js, раз уж его всё равно надо знать.
Ну и использование bdd-style проверок не делает тест автоматически проверяющим поведение. Я видел кучу юнит тестов, в которых проверки написаны в стиле expect/should.
В итоге — не переубедили :) Я всё ещё считаю что expect/should синтаксис — оверинжениринг из разряда "потому что можем" с сомнительным профитом
Тестирование RESTful API на NodeJS с Mocha и Chai