# Why are integration specs written in QUnit?

**URL:** <https://meta.discourse.org/t/why-are-integration-specs-written-in-qunit/45638>\
**Category:** Development\
**Created:** [14 يونيو 2016، 6:56ص UTC](https://meta.discourse.org/t/why-are-integration-specs-written-in-qunit/45638 "2016-06-14T06:56:21Z")\
**Posts on this page:** 1\
**Showing post:** 1

<div class="post-metadata">

**Author:** ![rimian](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/rimian/32/120658_2.png) [@rimian](https://meta.discourse.org/u/rimian)\
**Post date:** [14 يونيو 2016، 6:56ص UTC](https://meta.discourse.org/t/why-are-integration-specs-written-in-qunit/45638/1 "2016-06-14T06:56:21Z")

</div>

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 has a nice DSL that is easy to use. Not much ruby experience needed.
- Far less boiler plate code (javascript)
- RSpec can run single tests or groups of them (tags, etc) with options like --fail-fast
- Headless browser tests run faster
- Native output to stdout and correct exit code
- support for creating fixtures and transactional tests.
- There are already some integration specs in spec/integration

The list goes on. I’ve written complex AngularJS applications with RSpec integration tests. It’s pretty simple really.

---

_[View the full topic](https://meta.discourse.org/t/why-are-integration-specs-written-in-qunit/45638)._