I’m wondering what was the reason behind writing integration tests in QUnit when RSpec is available? The advantages of RSpec would be: Runs the phantomjs driver directly rather than through a shell command Removes the layer of abstraction on top of QUnit (really a unit testing framework) RSpec ha…

Do you mean RSpec as in lib/autospec/rspec_runner.rb main # frozen_string_literal: true module Autospec class RspecRunner < BaseRunner WATCHERS = {} def self.watch(pattern, &blk) WATCHERS[pattern] = blk end def watchers WATCHERS end # Di…

I am actually a fan of having a set of acceptance (high level) tests that allows us to test the entire stack at the same time. Note that acceptance tests are not the same as integration tests. Right now, our acceptance tests for the front end uses fixtures to stub the server’s response and that …

This is just a test runner. I mean something like this: discourse/spec/integration/category_tag_spec.rb at main · discourse/discourse · GitHub Also see: http://betterspecs.org/

[画像] rimian: Runs the phantomjs driver directly rather than through a shell command I am super confused here, there is no “ruby libphantomjs gem” any driver is going to have to run the phantomjs and pipe commands to it. Only way around this is to avoid the need for a real dom and use somethin…

I’m curious to know which tests do you classify as integration tests. We have alot unit tests for our Ember models, controllers, components and widgets which can’t be run and written in RSpec.

I see the acceptance tests are stubbing out http requests to the rails app. So, it’s not correct for me to call them integration specs because they don’t test the entire stack. You can however write the acceptance tests in RSpec or mini test.

ahh I’m probably confuse because of our different interpretation of the terms being used here. I was under the assumption that you were referring to acceptance tests as integration tests because it will then be possible to write those in RSpec using Capybara. However, majority of our Javascript test…

I usually use the term “smoke test” for those. discourse/spec/phantom_js/smoke_test.js at b3965eb06994fbe11b5a945efc99b136714b3fe3 · discourse/discourse · GitHub has got to pass for a build to be stamped with test passed. We have “integration” tests on the server that look at end-to-end server beh…

Another nice thing about RSpec/Capybara is that these tests are framework agnostic. As long as your application has a DOM (or in the case of ReactJS, a virtual DOM), you can write tests against it. So, theoretically, you can swap out your application architecture and your integration (or end-to-end)…

Why are integration specs written in QUnit?

Development

mcwumbly (Dave McClure) 2016 年 6 月 15 日午前 5:29 9

I realize I may be stepping into a quagmire with regards to terminology, but I like the term “end to end tests” to refer to and disambiguate tests that go through the client and server code together.

トピック		返信	表示
Headless qunit integration tests? Development	8	2072	2016 年 6 月 14 日
Developing Discourse Plugins - Part 6 - Add acceptance tests Developer Guides testing , plugin-guides , tutorial	32	18068	2022 年 6 月 2 日
Running a single test Development	2	2029	2016 年 6 月 25 日
Write end-to-end system specs for the Discourse user interface Developer Guides	3	780	2025 年 8 月 28 日
QUnit uses the nojs page Development	0	701	2017 年 2 月 27 日

Why are integration specs written in QUnit?

関連トピック