Writing unit tests is more of an art than a skill, and understanding what to test for comes with experience and/or mistakes. We look for the percentage of test coverage for examining the health of an application. However, the "coverage percentage" might be misused or overlooked. In particular, it falls victim to Goodhart’s law, which says: “When a measure becomes a target, it ceases to be a good measure”. Whenever we start writing test cases for the sake of improving the code coverage, we miss the whole point of testing and rather introduce Tautological Tests - poorly designed

Use spring to run RSpec - with spring - bundle exec spring rspec spec/controllers/api/v1/ Finished in 47.14 seconds (files took 1.58 seconds to load) 72 examples, 0 failures without spring - bundle exec rspec spec/controllers/api/v1/ Finished in 48.84 seconds (files took 29.23 seconds to load) 72 examples, 0 failures One of the reasons for RSpec tests being slow is the initial application boot time. This happens every time you make changes in your code and takes few seconds every time. You can reduce that by using spring to run your

While working with any application, testing plays most important role. Data is main requirement for writing proper test cases. We need different kind of data to test complex features and here factories plays important role. Data factory is blueprint that allows us to create an object, or a collection of objects, with predefined set of values. Factories makes it easy for us to define different kind of data. In rails or ember we create model object to write test cases. In rails many of us use FactoryGirl to create such test data using factories. Same way ember has FactoryGuy. Ember's

Rspec has great feature and that is trait. In rspec we create factory for each class which provides the simplest set of attributes necessary to create an instance of that class. Many times we need some attributes which we do not want to add in original factory and at the same time we do not want to repeat it. In such scenario rspec trait is good option. For few attributes we need different values and we want to use it at multiple places can be another reason to use it. Without Trait: FactoryGirl.define do factory :package do description FFaker:

What do you do when you need to run the same test multiple times, but with different parameters? If you copy and paste the test, you end up with a hard-to-read test file. You can’t easily tell how the tests differ from one another. Worse, when you need to change one, you need to change them all. Take the following simple test file: def double_it(number) number * 2 end describe '#double_it' do it 'doubles 1 into 2' do expect(double_it(1)).to eq(2) end it 'doubles 2 into 4' do expect(double_it(2)

Guideline for writing Good specs

Recently I added few integration tests in my projects using Capybara and Selenium webdriver and ran into banging my head against inconsistencies with test database. I create some records in test DB which were completely invisible to Selenium-driven browser-based tests. The problem is: the tests are being wrapped in database transactions, so any code running outside the actual test process (like, say, a server process servicing a Selenium-driven browser request) does not see the database records. Here are the steps to fix this problem - First of all, and this is very important, go into spec/spec_helper.rb and

Spec Improvements We were fixing some failing specs in one of our project, we noticed beside failures the spec timings was too high. We spent time not only to fix also improve the performance. During this process we learned few good practices and removed bad things we added earlier which helped us improved the performance. We had good amount of setup code for specs, for which we were using let statements. We can move the setup into a before(:all) block, replacing lets with instance variables. This will create the data only once, and as long as we never change

What does Integration testing mean ? Wiki says: Integration testing is the phase in software testing in which individual software modules are combined and tested as a group [Read More][1] When a software grows(may it be written in Ruby or Java or any other language for that matter), stability can become an issue as the application evolve and grow. Integration tests provide a great way to perform end-to-end tests that validate the application is performing as expected. The BDD-TDD life cycle goes as follows: Integration relates more towards BDD, so let's briefly get to know how BDD works. When

What is mock ? A mock is an object which we can use on behalf of another object. In short, mocking is creating (fake) objects that simulate the behavior of Real Objects. An object under test may have dependencies on other (complex) objects. To isolate the behavior of the object you want to test you replace the other objects by mocks that simulate the behavior of the real objects. When to mock ? Mocking is required when real objects are impractical to incorporate into the unit test. Most of the time external services or methods we have to mock. Once mocked, the