What’s the best way to (QUnit) assert an element on the page has some content in it?
This passes:
ok($.trim($('.foo').text()) == 'bar', 'content bar renders on page');
But isn’t very practical. Is there a better way?
I recently wrote some myself. The way I see it, the value hinges on the selector and the conditional.
Perhaps not the best example, but hopefully some help.
1 Like
Hi @Mittineague! I saw your plugin and I’ve got it running on my local instance. It helped me get my custom page up-and-running quickly.
Are you sure your tests fail correctly? When I run them, I get a pass regardless of the content:
ok(find("h1.mitt_newpage:contains('something else')"), 'heading displays something else not the heading');
This passes for me…
1 Like
Ah, yeah, you don’t want to use find() when dealing with :contains, you will want to use exists()
Example of it at
https://github.com/discourse/discourse/blob/master/test/javascripts/acceptance/search-full-test.js.es6#L274-L287
IIRC, that is because find() will still return an empty object back and should be used with assert.equal so you can compare a specific attribute of what you expected to find to an expectation.
exists will handle that object being empty and treat it as “not found” or “false”
https://github.com/discourse/discourse/blob/master/test/javascripts/helpers/assertions.js#L3-L5
4 Likes
Thanks. I was planning to write some “should nots” to go along with the “shoulds”, but then got sidetracked trying to get RSpec tests working (still trying) and hadn’t been back to the QUnit tests yet.
I can use a break from the RSpec roadblock so it will be a pleasant change to do the “should nots” and get those up to par.
1 Like
Interesting. I added 10 “not” tests, and sure enough, a lot of the tests that were passing were not passing for the reason I had thought they were.
Changing the "find"s to “exists” fixed most, except for four of them.
I changed the first problem test to an “equals” and discovered that although I specified currentUser as “TestRunner” instead of “Welcome TestRunner” it was “Welcome eviltrout”.
This apparently is coming from a fixture.
I don’t know if having plugins test against Core test fixtures is a great idea, but I guess it could work. Better would be for me to learn how to use my own fixtures that would be part of the plugin.
I’ve got RSpec running against my plugin here:
https://travis-ci.org/choiceaustralia/discourse-payments
https://github.com/choiceaustralia/discourse-payments
This is currently in early stages of development. I wouldn’t mind running capybara for feature specs. Much cleaner than running acceptance tests on top of QUnit.
1 Like