Desarrollando Plugins de Discourse - Parte 6 - Añadir pruebas de aceptación

Tutorial anterior: Developing Discourse Plugins - Part 5 - Add an admin interface


¿Sabías que Discourse tiene dos grandes conjuntos de pruebas para su base de código? En el lado del servidor, nuestro código Ruby tiene un conjunto de pruebas que utiliza rspec. Para la aplicación del navegador, tenemos un conjunto de pruebas qunit que incluye ember-testing.

Suponiendo que tienes un entorno de desarrollo configurado, si visitas la URL http://localhost:4200/tests comenzarás a ejecutar el conjunto de pruebas de JavaScript en tu navegador. Un aspecto divertido es que puedes verlo probando la aplicación en una ventana miniatura en la esquina inferior derecha:

La aplicación Discourse está construida con muchas pruebas que comenzarán a ejecutarse cuando visites la URL /tests. Por lo tanto, puede ser útil filtrar tus pruebas por el complemento con el que estás trabajando. Puedes hacerlo en la interfaz haciendo clic en el menú desplegable Plugin y seleccionando tu complemento:

Añadir una prueba de aceptación en tu complemento

Primero, asegúrate de tener la última versión de Discourse extraída. Poder ejecutar pruebas de aceptación desde complementos es una característica relativamente nueva, y si no extraes la última versión, tus pruebas no aparecerán.

Para este artículo, voy a escribir una prueba de aceptación para el complemento purple-tentacle que escribimos en la parte 5 de esta serie.

Añadir una prueba de aceptación es tan fácil como añadir un archivo a tu complemento. Crea lo siguiente:

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!");
  });
});

Intenté escribir la prueba de una manera que fuera clara, pero podría ser un poco confusa si nunca has escrito una prueba de aceptación antes. Recomiendo encarecidamente que leas la documentación de Ember sobre pruebas de aceptación, ya que tienen mucha información excelente.

En cada prueba que escribimos, necesitamos assert (afirmar) algo. En nuestra prueba, queremos hacer algunas afirmaciones para verificar si el tentáculo está oculto inicialmente y luego se muestra solo después de hacer clic en el botón.

Queremos definir un conjunto de acciones a realizar antes de hacer una afirmación. Para hacer eso, usamos la palabra clave await. Al usar esa palabra clave, esperamos a que la ejecución de cada ayuda asíncrona termine primero.

Nuestra primera acción de importancia es: await visit("/admin/plugins/purple-tentacle");. Esto le dice a nuestra prueba que navegue a esa URL en nuestra aplicación. Esa URL era la que mostraba el tentáculo.

Después de visitar la página donde aparece el botón del tentáculo morado, queremos verificar si podemos ver que el botón existe en la página y que la imagen del tentáculo aún no existe.

Eso se hace mediante las siguientes afirmaciones:

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

P.D. la versión anterior del complemento purple-tentacle no tenía el ID de elemento #show-tentacle en la plantilla handlebars. ¡Consulta la última versión para seguir el ejemplo!

Una vez que esas pruebas pasen, es hora de probar la interacción.

El siguiente comando es await click('#show-tentacle');, que le dice a nuestro marco de pruebas que queremos hacer clic en el botón y mostrar el tentáculo.

Después de simular un clic en el botón, podemos verificar si aparece el tentáculo afirmando:

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

¿No es tan malo? Puedes probar la prueba tú mismo visitando http://localhost:4200/tests?qunit_single_plugin=purple-tentacle&qunit_skip_core=1 en tu máquina de desarrollo. Deberías ver muy rápidamente aparecer el tentáculo morado y todas las pruebas pasarán.

Si deseas ejecutar las pruebas qunit del complemento desde la línea de comandos usando PhantomJS, puedes ejecutar

rake plugin:qunit['purple-tentacle']

(donde purple-tentacle es el nombre de la carpeta de tu complemento)

Depuración de tus pruebas

A medida que escribes tus complementos, tus pruebas pueden ayudarte a identificar problemas en tu complemento. Cuando estés desarrollando tus pruebas o si realizas cambios en el código de tu complemento, las pruebas pueden fallar. Para ayudar a entender por qué, Ember tiene algunas ayudas agradables: pauseTest() y resumeTest().

Para hacer uso de ellas, añade await pauseTest() dentro del código de tu prueba donde desees que la prueba se detenga. Ahora, cuando ejecutes tu prueba en el navegador, la prueba se pausará automáticamente en el punto donde añadiste pauseTest(). Esto te dará la oportunidad de inspeccionar la página o ver cualquier error para ayudar a depurar problemas.

Hacia dónde ir desde aquí

Odio sonar como un disco rayado, pero la documentación de Ember sobre pruebas es excelente. También podrías querer ver cómo Discourse prueba varias funcionalidades navegando por las pruebas en nuestro directorio de pruebas de JavaScript. Tenemos bastantes ejemplos allí de los que puedes aprender.

¡Felices pruebas!


Más en la serie

Parte 1: Conceptos básicos de complementos
Parte 2: Salidas de complementos
Parte 3: Configuración del sitio
Parte 4: Configuración de git
Parte 5: Interfaces de administración
Parte 6: Este tema
Parte 7: Publica tu complemento


Este documento está controlado por versiones: sugiere cambios en github.

30 Me gusta

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 Me gusta

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 Me gusta

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 Me gusta

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 Me gusta

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

1 me gusta

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 Me gusta

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 Me gusta

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 me gusta

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

nope,

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 mai 13 21:48 ./
drwxr-xr-x 20 tbp tbp 4096 mai 13 21:18 ../
drwxr-xr-x  6 tbp tbp 4096 mai 13 20:29 discourse-details/
drwxr-xr-x  6 tbp tbp 4096 mai 13 21:48 discourse-github-linkback/
drwxr-xr-x  6 tbp tbp 4096 mai 13 20:29 discourse-local-dates/
drwxr-xr-x  9 tbp tbp 4096 mai 13 20:29 discourse-narrative-bot/
drwxr-xr-x  7 tbp tbp 4096 mai 13 20:29 discourse-nginx-performance-report/
drwxr-xr-x  5 tbp tbp 4096 mai 13 20:29 discourse-presence/
drwxr-xr-x  3 tbp tbp 4096 mai 13 20:29 lazyYT/
drwxr-xr-x  9 tbp tbp 4096 mai 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?

1 me gusta

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 Me gusta

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

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 Me gusta