Разработка плагинов для Discourse - Часть 6 - Добавление приемочных тестов

Предыдущий урок: Developing Discourse Plugins - Part 5 - Add an admin interface


Знаете ли вы, что у Discourse есть два больших набора тестов для его кодовой базы? На стороне сервера наш код на Ruby использует набор тестов rspec. Для браузерного приложения у нас есть набор qunit, в который включен ember-testing.

Предполагая, что у вас настроена среда разработки, если вы перейдете по адресу http://localhost:3000/tests, вы запустите набор тестов JavaScript в своем браузере. Один из интересных моментов заключается в том, что вы можете видеть, как приложение тестируется в миниатюрном окне в правом нижнем углу:

Приложение Discourse создано с большим количеством тестов, которые начнут выполняться при посещении URL /tests. Поэтому может быть полезно отфильтровать тесты по плагину, над которым вы работаете. Вы можете сделать это в интерфейсе, нажав на выпадающий список Plugin и выбрав свой плагин:

Добавление приемочного теста в ваш плагин

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

В этой статье я напишу приемочный тест для плагина purple-tentacle, который мы создали в части 5 этой серии.

Добавление приемочного теста так же просто, как добавление одного файла в ваш плагин. Создайте следующее:

test/javascripts/acceptance/purple-tentacle-test.js

import { acceptance, exists } from "discourse/tests/helpers/qunit-helpers";
import { click, visit } from "@ember/test-helpers";
import { test } from "qunit";

acceptance("Purple Tentacle", function (needs) {
  needs.settings({ purple_tentacle_enabled: true });
  needs.user();

  test("Purple tentacle button works", async function (assert) {
    await visit("/admin/plugins/purple-tentacle");
    assert.ok(exists("#show-tentacle"), "it shows the purple tentacle button");
    assert.ok(!exists(".tentacle"), "the tentacle is not shown yet");
    await click("#show-tentacle");
    assert.ok(exists(".tentacle"), "the tentacle wants to rule the world!");
  });
});

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

В каждом написанном нами тесте нам нужно что-то assert (утверждать). В нашем тесте мы хотим сделать несколько утверждений, чтобы проверить, скрыт ли щупальце изначально и отображается ли оно только после нажатия кнопки.

Мы хотим определить набор действий, которые должны быть выполнены перед утверждением. Для этого мы используем ключевое слово await. Используя это ключевое слово, мы ждем завершения выполнения каждого асинхронного хелпера.

Наше первое важное действие: await visit("/admin/plugins/purple-tentacle");. Это указывает нашему тесту перейти по этому URL в нашем приложении. Этот URL был тем, который отображал щупальце.

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

Это делается следующими утверждениями:

assert.ok(exists("#show-tentacle"), "it shows the purple tentacle button");
assert.ok(!exists(".tentacle"), "the tentacle is not shown yet");

P.S. в предыдущей версии плагина purple-tentacle не было идентификатора элемента #show-tentacle в шаблоне handlebars. Проверьте последнюю версию, чтобы следовать инструкциям!

После того как эти тесты пройдут, пришло время протестировать взаимодействие.

Следующая команда — await click('#show-tentacle');, которая говорит нашему тестовому фреймворку, что мы хотим нажать кнопку и показать щупальце.

После того как мы имитируем щелчок по кнопке, мы можем проверить, появляется ли щупальце, используя утверждение:

assert.ok(exists(".tentacle"), "the tentacle wants to rule the world!");

Не так уж плохо, правда? Вы можете попробовать тест самостоятельно, перейдя по адресу http://localhost:3000/tests?qunit_single_plugin=purple-tentacle&qunit_skip_core=1 на вашей машине разработки. Вы очень быстро увидите появление фиолетового щупальца, и все тесты пройдут.

Если вы хотите запустить тесты qunit плагина в командной строке с использованием PhantomJS, вы можете выполнить

rake plugin:qunit['purple-tentacle']

(где purple-tentacle — это имя папки вашего плагина)

Отладка ваших тестов

По мере написания плагинов ваши тесты могут помочь вам выявить проблемы в вашем плагине. При разработке тестов или при внесении изменений в код плагина тесты могут не пройти. Чтобы помочь понять почему, Ember предоставляет несколько удобных хелперов: pauseTest() и resumeTest().

Чтобы использовать их, добавьте await pauseTest() в код вашего теста в том месте, где вы хотите, чтобы тест приостановился. Теперь, когда вы запустите свой тест в браузере, тест автоматически приостановится в точке, где вы добавили pauseTest(). Это даст вам возможность осмотреть страницу или просмотреть любые ошибки, чтобы помочь в отладке проблем.

Куда двигаться дальше

Мне не хочется звучать как сломанная пластинка, но документация Ember по тестированию отлична. Вы также можете посмотреть, как Discourse тестирует различные функции, просматривая тесты в нашем каталоге тестов JavaScript. Там есть довольно много примеров, из которых вы можете почерпнуть идеи.

Удачного тестирования!


Больше в серии

Часть 1: Основы плагинов
Часть 2: Пункты выхода плагина
Часть 3: Настройки сайта
Часть 4: Настройка git
Часть 5: Административные интерфейсы
Часть 6: Эта тема
Часть 7: Публикация плагина


Этот документ управляется версиями - предложите изменения на github.

30 лайков

OMG, have I put off writing tests for this long?!

A few things
I noticed you put an “id” into the template file that wasn’t there in the previous tutorial
I added 3 more tests to deal with the “Hide Tentacle” button I added
I needed to be logged in it is an Admin page
I needed to use port 4000 for my VirtualBox Vagrant set-up

Happily, quick success !

5 лайков

I’ve noticed a push to implement testing for plugins lately and I completely agree that this is important. I’ve been terrible at writing these in the past and want to get caught up.

I was considering the setup of Travis CI on a plugin repo as I noticed the ability to use Docker with Travis. But having never touched Travis before, is it possible to do this with a plugin? It would be nice to submit PRs to my own repo and have the tests run automatically.

5 лайков

how can I run single ember tests on the browser?

http://localhost:3000/qunit?module=Acceptance%3A%20Purple%20Tentacle

I mean, if I have another acceptance test called “another test”, how would I run it? Thank you!

If you click “rerun” beside a test, you’ll get a URL that is just for that particular test that you can refresh over and over.

You can also run by module by clicking in the “All Module” box and checking off just the modules you want to run.

2 лайка

This tutorial needs updating to replace ok(...) with assert.ok(...).

Have put the necessary changes in a PR - I’m happy to edit the OP if it’s made into a wiki :slight_smile:

https://github.com/eviltrout/purple-tentacle/pull/2

2 лайка

OK it is wikified! PM me if anything else needs this treatment any time.

1 лайк

A note after writing some basic acceptance tests for the Elections Plugin:

  • If you use the default loggedIn option, you’re logged in as eviltrout with the properties in this session fixture

  • You can login as a custom user (necessary if you’ve added custom user properties) by defining your own session fixture and setting it as the current user using the beforeEach hook. See here for an example.

@eviltrout is there a better way of using a custom user for acceptance tests?

5 лайков

What we should probably do is change the acceptance method in discourse to take an argument for the user to log in as. Then your test could say { loggedIn: true, logInAs: angus }

If you’ve got time for that PR we’d accept it!

4 лайка

q: how to run the ruby tests tests for a plugin?

i am trying to run the tests for discourse-github-linkback, but i have no idea how.

After some stackoverflow i tried this (and i got some errors):

~/discourse$ bundle exec rspec ./plugins/discourse-github-linkback/spec/lib/github_linkback_spec.rb 

An error occurred while loading ./plugins/discourse-github-linkback/spec/lib/github_linkback_spec.rb.
Failure/Error: CoreExt::ActiveSupport.without_bootsnap_cache { super }

NameError:
  uninitialized constant GithubLinkback
# ./plugins/discourse-github-linkback/spec/lib/github_linkback_spec.rb:3:in `<top (required)>'
# ------------------
# --- Caused by: ---
# NameError:
#   uninitialized constant GithubLinkback
#   ./plugins/discourse-github-linkback/spec/lib/github_linkback_spec.rb:3:in `<top (required)>'
No examples found.

Randomized with seed 60987


Finished in 0.02025 seconds (files took 3.36 seconds to load)
0 examples, 0 failures, 1 error occurred outside of examples

Randomized with seed 60987

Note that i see the plugin in the local discourse dev admin page, so i hope it is correctly installed (into ~discourse/plugins/

Simplest way, run bin/rake autospec, and save the file

1 лайк

From what i see, doing cd ~/discourse and then running

runs all the tests for discourse.

On my ubuntu 18.04 VM with i5 6500, this has been running for half an hour already.
It feels wrong to run the whole tests suite when i only want to run the tests in that one plugin.
(this is especially so when i probably will modify my tests again, at least a few times)

Did i do something wrong?

Let me guess, you are symlinking your plugin vs checking out directly to the path under plugins

no,

tbp@tbp-linux-dev:~$ cd ~/discourse/plugins/
git clone -b allow-all-user-repositories-wildcard https://github.com/TheBestPessimist/discourse-github-linkback
tbp@tbp-linux-dev:~/discourse/plugins$ ll
total 40
drwxr-xr-x 10 tbp tbp 4096 May 13 21:48 ./
drwxr-xr-x 20 tbp tbp 4096 May 13 21:18 ../
drwxr-xr-x  6 tbp tbp 4096 May 13 20:29 discourse-details/
drwxr-xr-x  6 tbp tbp 4096 May 13 21:48 discourse-github-linkback/
drwxr-xr-x  6 tbp tbp 4096 May 13 20:29 discourse-local-dates/
drwxr-xr-x  9 tbp tbp 4096 May 13 20:29 discourse-narrative-bot/
drwxr-xr-x  7 tbp tbp 4096 May 13 20:29 discourse-nginx-performance-report/
drwxr-xr-x  5 tbp tbp 4096 May 13 20:29 discourse-presence/
drwxr-xr-x  3 tbp tbp 4096 May 13 20:29 lazyYT/
drwxr-xr-x  9 tbp tbp 4096 May 13 20:29 poll/
tbp@tbp-linux-dev:~/discourse/plugins$ 

Can you confirm you tried saving the spec file once it was running, cause it is meant to interrupt stuff and start running the plugin spec?

since the initial bin/rake autospec is still running, there was/is no “save spec file” message yet.
also, by running bin/rake autospec --help, i saw no --save option.

I didn’t understand what save the file meant, so my full command was bin/rake autospec > spec.rb ← probably this is wrong

I meant in Vim or whatever you use, save the spec file, there is a watcher on it that will invoke the spec runner once it is saved.

Also see: How do I run only discourse/plugins/poll/spec? - #6 by tgxworld

1 лайк

Finally i did it :^).

With the help of that link, i ran the tests by using this command:
bundle exec rake plugin:spec["discourse-github-linkback"]
and, ofc, i was in ~/discourse when doing that.

Thanks for all your help @sam!

(1st PR for discourse-plugin babyyyyy :tada:)

8 лайков

My Qunit-Tests aren’t executed or at least they don’t show me any output.
They finish with the following:

No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.
Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received

Travis.CI Result - Travis CI
Test-File - GitHub - kokoro-ko/discourse-humble-box: humble-bundle onebox · GitHub

I am not that skilled with CI yet and haven’t found my mistake by now.

Do your tests pass if you visit /qunit on your development environment? How about if you run rake plugin:qunit[discouse-humble-box]?

2 лайка