search

PursuanceProject / pursuance

Pursuance: end-to-end encrypted task management optimized for large numbers of volunteers. We are building a vast and formidable ecosystem of opposition to institutionalized injustice.
https://pursuanceproject.org/
Other
134 stars 15 forks source link

***DO NOT MERGE*** Create a test suite for the Login/Signup page ***DO NOT MERGE*** #173

Closed ghost closed 6 years ago

ghost commented 6 years ago

This commit lays the groundwork for a pursuance test suite and adds a few simple tests for the login page. I've added the WebdriverIO test framework, the Chai assertion library, and some Babel support for writing ES6/ES2015 code. I'll add a README-TESTING.md soon. In the meantime, to try this out, pull the branch, say npm install to update the installed packages with a bunch of infrastructure, and then invoke WebdriverIO's test runner thus:

npm run wdio

> pursuance@0.1.0 wdio /home/kwall/gocode/src/github.com/PursuanceProject/pursuance
> node -r babel-register ./node_modules/.bin/wdio

------------------------------------------------------------------
[firefox #0-0] Session ID: 17bf44f7-7e65-4efc-8a75-94cba4bed05d
[firefox #0-0] Spec: /home/kwall/gocode/src/github.com/PursuanceProject/pursuance/src/components/NavBar/LogIn/LogIn.test.js
[firefox #0-0] Running: firefox
[firefox #0-0]
[firefox #0-0] Pursuance login
[firefox #0-0]   ✓ should have a Log in link
[firefox #0-0]   ✓ should accept username input
[firefox #0-0]   ✓ should accept password input
[firefox #0-0]   ✓ should accept a valid username/password combination
[firefox #0-0]   !! should have a logout button
[firefox #0-0]   !! should reject an unknown username
[firefox #0-0]   !! should reject an invalid password
[firefox #0-0]
[firefox #0-0]
[firefox #0-0] 4 passing (4s)
[firefox #0-0] 3 pending
[firefox #0-0]

==================================================================
Number of specs: 8

4 passing (6.00s)
3 skipped

I imagine we'll have some conversations about this first. :)

It linted noisily, but browser is, in fact, defined globally by the test runner.

$ npm run lint
> pursuance@0.1.0 lint /home/kwall/gocode/src/github.com/PursuanceProject/pursuance
> npm run verify-eslint-rules && eslint --fix ./src && npm run format

> pursuance@0.1.0 verify-eslint-rules /home/kwall/gocode/src/github.com/PursuanceProject/pursuance
> eslint --print-config .eslintrc | eslint-config-prettier-check

No rules that are unnecessary or conflict with Prettier were found.

/home/kwall/gocode/src/github.com/PursuanceProject/pursuance/src/components/NavBar/NotificationsModal/NotificationsTab/NotificationsTab.js
  31:20  error  'FaSliders' is not defined  react/jsx-no-undef

✖ 1 problem (1 error, 0 warnings)

npm ERR! code ELIFECYCLE
ghost commented 6 years ago

@elimisteve A first test to get us on the same page.

ghost commented 6 years ago

@elimisteve If you're okay with this proof-of-concept, shall I proceed? The next steps are writing the README-TESTING.md and fleshing out the test. In particular, best practice is decoupling test logic and page-handing logic using page objects. Google "page object model" for deets, but the idea is that test files should not directly call any Webdriver code -- this lets tests remain unchanged if or when the underlying page elements change.

ghost commented 6 years ago

@elimisteve This PR, or one like it, would probably satisfy issue #66, too.

elimisteve commented 6 years ago

It linted noisily, but browser is, in fact, defined globally by the test runner.

Is it? I guess since browser isn't defined in most of the .test.js files, is why it's complaining.

elimisteve commented 6 years ago

...best practice is decoupling test logic and page-handing logic using page objects. ...the idea is that test files should not directly call any Webdriver code -- this lets tests remain unchanged if or when the underlying page elements change.

Sounds reasonable to me, but do you happen to have a quick example you can show me?

ghost commented 6 years ago 
It linted noisily, but browser is, in fact, defined globally by the test runner.

Is it? I guess since browser isn't defined in most of the .test.js files, is why it's complaining.

That was my guess, too. The testrunner defines browser for the test environment, but I did not know how to tell lint that. Turns out that a wdio plugin exists that does, eslint-plugin-webdriverio. Added that as a dev dependency, problem solved.

ghost commented 6 years ago

Sounds reasonable to me, but do you happen to have a quick example you can show me?

Yep. https://gist.github.com/kurtwall/baf78d670bf4e139d0e89f3c08c819e3

That's a slight modification of WDIO's example page object, not something specific to Pursuance. OTOH, what we end up with will look a lot like that.