The Highgroove blog. Sit pit-side with us to learn how we work. Sometimes technical, sometimes business-oriented, but always focused on simple solutions.
You are browsing posts about Testing. Check out all posts on our blog.
by drice
I've been developing Rails applications since version 1.2. Having worked through several major Rails upgrades, I've learned the true value of writing tests. Simply put, tests provide confidence that features will work as designed, and will continue to work in the future. Read on and I'll delve into my own process of deciding what to test.
→ Read More
Highgroovers take test-driven design (TDD) seriously, but it's easy to become overwhelmed by the number of tools available for testing applications. However, if you know us even a little, you know that we have a lot of experience using different tools—and that we've developed some opinions about them.
To help others narrow down the options, I asked a couple of developers here how they felt about the two most popular tools for acceptance-level testing: RSpec and Cucumber.
→ Read More
by aubrey
At Highgroove, we aim to be fast. When we jump on a project, we work with the client to understand their goals and begin delivering functionality on the first day. As the project progresses, we strive to increase the velocity of work on the project with each passing iteration.
Our ability to deliver high-quality work at an ever-increasing rate depends heavily on our process—specifically, the three things we do on every project.
→ Read More
by jonathan
Hey, have you heard about the first Highgroove-hosted Code Retreat? We're polishing our silverware and painting the walls in preparation[1] for helping developers to level-up their skills.
Read on to find out more.
→ Read More
by aubrey
Last month on the 37signals blog, DHH wrote about testing like the tsa. In the article David argues for less strict test driven development and quotes Kent Beck in saying:
I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don’t typically make a kind of mistake (like setting the wrong variables in a constructor), I don’t test for it.
At Highgroove, we feel this approach is not for everyone. Read on for more details on our approach.
→ Read More
At Highgroove we really like testing and are constantly looking for ways to improve our testing process, how quickly our tests run, and how exactly we execute our tests. How often during your Test Driven Development (TDD) cycle do your tests fail "mysteriously"? You've written your tests, written your code, and most of them pass but one or two stubbornly fail even though you are fairly certain they should pass given the testing setup you've provided? At Highgroove we bias towards action so we are likely to launch a debugger session or a pry session to get to the bottom of this. Another approach, which won't break your existing TDD workflow, is to use your test-suite in place of a more traditional debugger. After the jump we'll talk about how we've been using this strategy to dig into code quickly and easily.
→ Read More
Database-bound tests are a drag. Inconsistent tests are a pain. Database-bound, inconsistently failing tests are the worst!
The following commit message is from a real code base:
Run in transactions by default.
When we added controller specs they weren't being run w/any kind of DB cleaner b/c there was no default strategy and they weren't explicitly included in a group. Now, we use :transactions be default, setting request specs to use :truncation
Also, I saw a 2 second speed up from this change!
Let's look at what we changed in this commit to turn our inconsistently failing database-bound tests into slightly faster, consistent, database-bound tests.
→ Read More
by mike
I started watching Gary Bernhardt's Destroy All Software screencasts recently and after watching a specific episode, I had to have his Ruby testing setup. After sitting in Vim config for a while, with some improvements I made, I started feeling like I should somehow contribute my changes back. After I started adding a few more changes suggested by fellow Taconaut Steven Harman, I decided it really needed to be a Vim Plugin.
→ Read More
by stafford
One of my least favorite chores as a developer is dealing with email. I’m not talking about my inbox. That is a post for another day ;). I’m talking about emails sent by web applications. Whether it is a sign up confirmation email, a receipt from a purchase, or reminder for your dog’s birthday. Chances are, if you have a web application, it sends email.
Traditionally, my workflow for testing these emails has not been very elegant or even efficient. It would either involve creating a bunch of users with different emails accounts I own, or telling the back-end to send all emails to my email address. While both of these work to some extent, the former is very time consuming and the later isn’t really testing the system the way it is meant to be used.
Mailcatcher one-ups both of these methods big time. Mailcatcher provides you with a local SMTP server for you to send your emails to in your development environment. Mailcatcher also provides you with a webmail interface to view all the emails your system has sent.
→ Read More
It's easy to say "We're agile" and "We use Behavior/Test Driven Development" and thus "we use the right tools to empower our developers!" but what are those tools? For me that discussion is entirely about the tool stack you choose, how that stack empowers you as a developer to do things right the first time. Luckily thanks to the ruby community as a whole we have a large number of high-quality choice to choose between.
→ Read More
by andy
One of the more complicated Ruby/Rails projects we work with at Highgroove has many points where it interacts directly with the filesystem.
Writing tests for an application whose code requires reading from or writing to the filesystem presents challenges, especially if done naively.
While it's tempting to simply use the real filesystem during unit tests, this presents a few problems:
So what's the solution? Fake the filesystem during unit tests.
More after the break.
→ Read More
At Highgroove Studios, we're hyperspecialists in Ruby on Rails web application development. Not only do we write amazingly complicated code on time and on budget, but we follow up all our work with tests so we know our code works.
This is not without its problems however, as a test suite can become just as bloated and difficult to update as the code base it tests! This week, I'll talk about some of the ways I've learned to approach writing tests.
→ Read More
by brandon
Here at Highgroove we often use the popular Factory Girl gem in our tests.
I also like to use a data generation library like Forgery in combination with Factory Girl.
Forgery allows me to improve my factories by using realistic instead of contrived data.
For example, → Read More
