Home - Chai. Code School - Testing with RSpec. #275 How I Test. Here I show how I would add tests to the password reset feature created in the previous episode. I use RSpec, Capybara, Factory Girl, and Guard to make request, model, and mailer specs. Download: source codeProject Files in Zip (92.2 KB)mp4Full Size H.264 Video (26.4 MB)m4vSmaller H.264 Video (16.1 MB)webmFull Size VP8 Video (18.1 MB)ogvFull Size Theora Video (37.8 MB) #412 Fast Rails Commands. Apr 04, 2013 | 8 minutes | Tools Rails commands, such as generators, migrations, and tests, have a tendency to be slow because they need to load the Rails app each time. Here I show three tools to make this faster: Zeus, Spring, and Commands.
Download: source codeProject Files in Zip (44.5 KB)mp4Full Size H.264 Video (21.7 MB)m4vSmaller H.264 Video (9.71 MB)webmFull Size VP8 Video (10 MB)ogvFull Size Theora Video (22.4 MB) Everyday Rails Testing… by Aaron Sumner. Have you gotten your hands dirty with a Rails application or two, but lack reliable test coverage? Does your application testing consist of a series of browser clicks, hoping you cover everything? Or do you just cross your fingers and hope for the best that everything will just work? Don't worry, everyone has been there at some point--and while testing and test-driven development are important aspects of Rails development, many tutorials gloss over these components. In Everyday Rails Testing with RSpec, I'll show you how I got past that hurdle, increasing my code's trustworthiness and saving untold time in browser-based testing.
Everyday Rails Testing with RSpec contains six chapters based on content from the Everyday Rails blog, along with six additional chapters exclusive to the book and complete code for a simple, but tested Rails application. Ruby flew too: Rails 3.2, MiniTest Spec and Capybara. What do you do when you love your spec testing with Capybara but you want to veer off the beaten path of Rspec and forge ahead into MiniTest waters? Follow along, and you'll have not one, but two working solutions. The setup Quickly now, let's throw together an app to test this out. I'm on rails 3.2.9. Edit the Gemfile to include a test and development block Note the inclusion of database_cleaner as per the capybara documentation And bundle: We will, of course, need something to test against, so for the sake of it, lets throw together a scaffold, migrate our database and prepare our test database all in one big lump.
Make it minitest To make rails use minitest, we simply add a require statement to our test_helper.rb: We can add in a quick integration test to verify that everything is working correctly up to this point: If you are that way inclined, you could create an "acceptance" directory and pop your tests in there instead. Now edit the book_spec.rb file we created Running this passes nicely: Use RSpec.vim with tmux and Dispatch. (And Keep Your Screen Real Estate) As you may know, there are quite a few of us now working at thoughtbot. While we share a lot of the same opinions, we all work a little differently. Most of us are running specs from Vim using RSpec.vim. Some of us use RSpec.vim with tslime. I enjoy a different setup with Dispatch. Dispatch I like to use my whole screen for editing or referencing documentation in a browser, so I don't keep multiple tmux splits most of the time.
Instead of using tslime.vim to send tests outside of Vim, I enjoy using Tim Pope's Dispatch to automatically open a new tmux split to run asynchronously, or to send the command to Bash to be run synchronously. This output is captured inside a Vim split which you can easily move to and use ^] (Ctrl-]) to have Vim jump directly to the failing test. Here's a video showing what Dispatch is all about: Setting things up While either Dispatch or RSpec.vim could be used independently, they have a real power when used together. Some RSpec Tips and Best Practices - bitfluxx.com. I’ve been working a lot with RSpec lately, in close conjunction with my coworker Myron Marston, who happens to be a committer to RSpec. He’s shown me how a lot of features in RSpec work, how they’re useful and some best practices to use. I thought I’d share some of my favorite ones. let{} I used to write specs like this: describe User, '#locate' before(:each) { @user = User.locate } it 'should return nil when not found' do @user.should be_nil endend Note the use of the @user instance variable for the user.
Instead, you should use let{}: It is memoized when used multiple times in one example, but not across examples. So to rewrite the example above using let{}: describe User let(:user) { User.locate } it 'should have a name' do user.name.should_not be_nil endend There is also a let! Enhanced it_should_behave_like Shared example groups were one of those RSpec features that seemed useful in concept, but I found hard to actually use effectively.
Passing context in Passing in arguments Much better. Thoughts.inject(world), RSpec best practices - RSpec best practices. A Post Entitled RSpec best practices A few days ago Philippe Creux posted his RSpec Best Practices and Tips. The post is well worth reading even if you prefer another test framework (you are testing, right?!) Because there are several tips that are applicable to TDD more broadly than rspec alone. Of all the tips there are two that I cannot re-emphasize strongly enough: “Only One Expectation Per It Block” and “(Over)Use Describe and Context”. Single Expectation Tests The “one expectation” tip is more broadly expressed as “each test should make only one assertion.” The impetus for a monolithic test is typically the perceived advantage of collecting all the similar expectations into one place.
Try the following [:name, :age, :gender].each do |expected_attribute| it { should respond_to expected_attribute } end This code retains the advantages of both co-locating similar kinds of tests and employing discrete “one expectation” tests. Context is King The “(Over)Use Context” tip is spot on. Beginning Rails testing.
January 11, 2011 I admit that I was guilty for a long time of not writing any tests for my Rails applications. My application testing consisted of an unhealthy reliance on in-browser testing, with nothing automated. I blame this on coming from a very unstructured way of developing code before I discovered Rails; I also think the early Rails demonstrations (15-minute blog) and tutorials focused on rapid application development more than the baked-in opportunities to test your code programatically. This wasn’t the end of the world when I had one small app in production, and hardly any users—but as the apps grew in count, size, and complexity, and my user base grew along with them, manually testing every edge case, every time, in a browser became tedious.
It really wasn’t until I read early beta versions of a couple of books on testing that I finally got with the program. Below are five things I did to get in the swing of testing my Rails applications. 1. 2. 3. 4. 5. Next steps Buy now. WebDriverJs - selenium - A guide to using the JavaScript bindings for WebDriver. - Browser automation framework.
Getting Started (requires Node v0.8+) To get started with WebDriverJS for Node, you will need to download a copy of the ChromeDriver and ensure it can be found on your system PATH. All other browsers can be tested using the stand-alone Selenium server. Once you've obtained the ChromeDriver and placed it on your PATH, you can run your first test: var webdriver = require('selenium-webdriver'); var driver = new webdriver.Builder(). withCapabilities(webdriver.Capabilities.chrome()). build(); driver.get(' { return driver.getTitle().then(function(title) { return title === 'webdriver - Google Search'; });}, 1000); driver.quit(); Reference API Docs Installing from NPM % npm install selenium-webdriver Building from Source % git clone cd selenium% .
Using the Stand-alone Selenium Server server.start(); Promises. Selenium - Web Browser Automation. Better Specs { rspec guidelines with ruby } Everyday Rails. 6: Top 5 Cucumber best practices. This is the sixth episode of our Testing Tuesday series. Every week we will share our insights and opinions on the software testing space. Drop by every Tuesday to learn more! Last week we talked about testing web applications with Selenium. How to use Cucumber – best practices Once you get started with Cucumber, the question is how to write your features. How can you keep your features maintainable so you don’t have to correct them after each change in the application?
Following I list 5 best practices that help us in our daily Cucumber life at Codeship. 1. Scenarios should be written like a user would describe them. Declarative features are vivid, concise and contain highly maintainable steps. 2. Narratives describe in about one sentence what a feature does. 3. When you encounter a Cucumber step that contains two actions conjuncted with an “and”, you should probably break it into two steps. 4. In Cucumber you can reuse steps in other steps. 5. Further information: Rails API Testing Best Practices With RSpecMatthew Lehner. Writing an API is almost a given with modern web applications. I’d like to lay out some simple guidelines and best practises for Rails API testing. We need to determine what to test and why it should be tested. Once we’ve established what we will be writing tests for, we will set up RSpec to do this quickly and easily.
Basically we’ll be sending HTTP requests and testing that the response status codes and content match our expectations. What to test? A properly designed API should return two things: an HTTP response status-code and the response body. Testing the status-code is necessary for web applications with user authentication and resources with different permissions. HTTP Status Codes Typical HTTP responses for a simple API on an application with authentication will generally fall within the following 4 status codes: If you’re wondering why not just use 401 - Unauthorized or 403 - Forbidden for every permission/auth error, I’d suggest reading this stackoverflow answer. Response Body. TDD JavaScript with Require.js and Teabag on Rails - Inline Block's Blog. Introduction Test Driven Development, or TDD, is the process of writing tests before writing your code. Or minimally, testing the code that you write.
Since starting to use require.js, I found it annoying that there were not many test runners in rails that would support require. I did find that Teabag had partial require support by defering the execution of tests until certain assets are loaded. However, once we integrated Teabag, we found that it didn’t always wait correctly. We also needed to hardcode or use our templating language output JavaScript that would include all our tests, even though Teabag knew what all our tests were.
Our modifications basically used require itself, to include the found tests (see: suite.matcher) and pull them in, then once loaded, run Teabag.execute. Setting up Teabag First we need to add the gem to your Gemfile. Now run their rake installer. Then setup your test suite. Now we will include chai into our spec helper. Writing a test And there you go.
AngularJS Pain Points - Jaco Pretorius. I’ve been using AngularJS for almost 3 months. I had heard quite a lot about Angular before this time – many people were talking about it being the ‘next big thing’ and how it could become the defacto JavaScript framework for client-side development. At first glance I was very impressed with Angular – the two-way binding removes the need for constantly updating the view and the scope objects makes for a clean separation between the controller and the view. There were other elements which were very appealing as well – a complete documentation site, a focus on testability, and a clean separation of concerns through built-in dependency injection. As I said, at first glance it definitely looks very impressive. Now that I’m more familiar with AngularJS I am unfortunately less impressed.
The Documentation I’ve spoken to other developers who use Angular and the common complaint is always about the documentation. Afterwards, bootstrap your app with this new module. The Testing. Getting Started With Konacha: JavaScript Testing on Rails. Konacha is a testing tool for JavaScript applications running on Rails. Why Konacha? It’s very fast.It treats JavaScript like a first-class citizen: Your tests are written in JavaScript, call into JavaScript code, and inspect JavaScript objects.
You can still trigger events, e.g. with jQuery, if you need to simulate user actions.It comes with support for the Rails asset pipeline. [1]It supports CoffeeScript.You can use the in-browser runner (good for development), or run your test suite from the command line through Selenium (good for build servers). What it cannot do is talk to the server. In particular: It cannot use the database.It cannot access your Rails (server-side) views. Any DOM nodes you are testing need to be created on the client side (for instance with JST templates), not served out by views.
When you need either of these two, write integration tests with Capybara instead. Tutorial: Overview Testing Plain JavaScript To test this, first add Konacha to your Gemfile: Testing the DOM. Noelrappin/summer_breeze. Summer Breeze: creates dynamic Rails fixtures for Jasmine tests. On stage at Red Dirt Ruby Conference, Noel Rappin has released Summer Breeze, a gem that makes working with Jasmine in Rails a bit easier. Summer Breeze dynamically creates Rails fixtures for your Jasmine tests. Installation and usage To install via RubyGems: gem install summer_breeze … and run the bundled generator: rails generate summer_breeze:install Now you can define you fixtures in the generated initializer: fixture "PostsController##index.body_container" You then have several options for telling Jasmine about your new fixture: sb.loadFixture(fixture_name) sb.findSelector(fixture_name, selector) sb.readFixture(fixture_name) A sample test might look like: it("hides text when asked", function() { $form_container = sb.findSelector('login', '.form_container'); toggle_handlers.init(); $hide_link = $form_container.find(".toggle_link"); expect($hide_link).not.toHaveClass("hidden"); $hide_link.click(); expect($hide_link).toHaveClass("hidden"); }); [Source on GitHub]
Sucking less at writing Cucumber — Rendered Text. Charliesome/better_errors. Cane - Ruby code quality thresholds. Code Tools · metricfu/metric_fu Wiki. Metricfu/metric_fu. Behavior-driven development. With Proper TDD, You Get That. Search · ttt-ruby. Agile Development of Frontend Javascript using AngularJS, Jasmine, Testacular & Jenkins | Agile India 2014 Conference Submission System. Comparing googlemock to Mocha. Not Tending to "The Build" – A Common Anti-Pattern. Test Driven Development: Resistance Is... Perplexing? A Beginning Developer's Experience With TDD.
Cucumber - Making BDD fun. Tip: Run seeds.rb file only against Development. Intern: A next-generation JavaScript testing stack. Summer Breeze: creates dynamic Rails fixtures for Jasmine tests. Sextant-view-your-rails-routes-without-waiting-on-rake/ Better Rails development with better_errors! Testing your site (Part 1) A Primer on A/B Testing. Selenium - How to test Mobile app using cucumber-ruby with selenium2 webdriver. Testing tuesday #8 | Search Results | LINK Medical Computing, Inc: LINKTools® HL7 Basic_Home.
Advanced TDD/BDD Master class - Learn TDD/BDD from the author of BDD in Action. Should I Write a New Unit Test? Linksheet: Cucumber and BDD. 7: Managing test data with factory girl. 8: Behavior-Driven Integration and Unit testing. 6: Top 5 Cucumber best practices. 19: How to test node.js applications with Jasmine. 18: How to test asynchronous JavaScript with Jasmine. 17: How to spy on JavaScript methods with Jasmine. 16: Javascript testing with Jasmine. How to set up Cucumber with your Ruby and Rails projects. 15: How to set up Cucumber. 14: How to set up RSpec. 13: Integration tests vs. Bogus. 12: EuRuKo 2013. 11: Reliable mocks with Bogus. 10: Designing code with RSpec. 9: Stubbing and Mocking with RSpec. Testing Tuesday #1: Tests make software. 2: From Test-Driven Development to Behavior-Driven Development. Testing Tuesday #5: Test your web apps with Selenium. 4: Continuous Integration and Deployment with Cucumber. 3: Behavior-Driven Development with Cucumber.
Better Specs { rspec guidelines with ruby } Vojtajina/ng-directive-testing. Rails Conf 2013 BDD and Acceptance Testing with RSpec & Capybara. Angular Modules and RequireJS best practices? Rb: Rspec views with Rails 3. Headless Functional Testing with Selenium and PhantomJS. Testing JavaScript with PhantomJS.
Full stack integration testing with Rails3: browser-oriented, JavaScript, continuous integration - Muriel's Tech Blog. Wrong/examples.rb at master · alexch/wrong. The wrong way. Wrong. Secrets of the Chrome Developer Tools. Efficient Rails Test-Driven Development, Classes 1 ~ 6. Learn Ruby on Rails Testing. Mocks Aren't Stubs. Introducing BDD | Dan North. What’s in a Story? | Dan North. Get started with testing from top to bottom. Testing Tuesday 1 ~ 12. How I learned to test my Rails Apps parts 1 ~ 5. Test Your Rails Application Configuration.
Scripted GUI Testing with Ruby.