Permalink

Testing Tuesday #10: Designing code with RSpec

  • Twitter
  • Facebook
  • HackerNews
  • Reddit
  • LinkedIn
  • Google Plus
  • Email
  • RSS
  • StumbleUpon
  • Tumblr

This is the tenth Testing Tuesday episode. 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 using stubbing and mocking to specify your examples behavior-driven with RSpec.


Design your code with stubs in RSpec

It’s great to be able to stub existing code to become independent from other components’ behavior. But it’s even better that you can stub code that doesn’t exist before you implement it.

Stubbing code that isn’t even there yet is a great way of designing your application. Instead of taking the code that already exists, you think of the code you wish you had. Stubs let you specify what you wish your code looked like by simulating methods the way they should behave. Step by step you implement the stubbed methods afterwards, guided by your integration tests that point out what to implement next.

This approach leads to readable, maintainable and reusable code. In this screencast we walk you step by step through this design process.

Up next Testing Tuesday: Check your stubs and mocks with Bogus

In the last two Testing Tuesday episode we made sure that all our stubbed and mocked behavior also works in the “real” world by running our Cucumber scenarios. This can become cumbersome though. A faster approach is to use Bogus, that checks the methods you’re stubbing for you. Learn more next Testing Tuesday!

Further info:

Permalink

Testing Tuesday #9: Stubbing and Mocking with RSpec

  • Twitter
  • Facebook
  • HackerNews
  • Reddit
  • LinkedIn
  • Google Plus
  • Email
  • RSS
  • StumbleUpon
  • Tumblr

This is the ninth Testing Tuesday episode. 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 Behavior-Driven Integration and Unit Testing with Cucumber and RSpec.


Specifying examples with RSpec

When you work Outside-In with Behavior-Driven Development your scenarios take care of checking that your application works from a user’s perspective. They don’t care at all how you implement something.

Let’s say we refactor a class of our application. Then we permanently want to make sure that we didn’t break anything by moving things around. Unfortunately this is impossible with integration tests, because they are just too slow.

This is why we write examples that explain how our single components – like for example classes – should behave. These examples should be fast, so we can run them continuously while we make changes to a class. And they should only specify behavior of the own scope and ignore all behavior of other classes.

I am working in a Ruby on Rails App so I use RSpec to write these examples in this screencast, but there are Spec frameworks for a lot of other languages that work similar. Check out the further info section below to find out more.

Stubbing and Mocking with RSpec

Stubbing and Mocking makes your component examples independent of other components. You can stub methods on objects to let them return whatever you like. And you can use mock objects to replace instances of other classes. This screencast shows how to stub and mock using RSpec.

Up next Testing Tuesday: Design your application with RSpec

Stubbing and Mocking also facilitate designing software. They let you specify the code you wish you had without relying on code that’s already there. This makes you build better designed and more readable code. Check back next Testing Tuesday to find out how!

Further info:

Permalink

Testing Tuesday #8: Behavior-Driven Integration and Unit Testing

  • Twitter
  • Facebook
  • HackerNews
  • Reddit
  • LinkedIn
  • Google Plus
  • Email
  • RSS
  • StumbleUpon
  • Tumblr

This is the eighth Testing Tuesday episode. 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 how to manage your integration test’s data with factory_girl.


Using Integration Testing and Unit Testing with Behavior-Driven Development

Traditionally application code is written first and tests afterwards. After writing a piece of code, you write unit tests. And once you finished a few pieces of code, you write integration tests to see if they fit together.

In Behavior-Driven development there is an approach called Outside-In Development where we go the other way round: We write our scenario first, and in order to make it work we write examples for single components. The application code comes last.

This is our development cycle:

  1. Specify a scenario
  2. Run the scenario and watch it fail
    1. Specify the behavior of a component in an example to fix the failure
    2. Run the component specification and watch it fail
    3. Implement the minimum functionality necessary to make the example work
  3. Run the feature again. If it still fails, continue with A.
  4. The scenario works! Write another scenario until the feature is complete.

Developing software Outside-In has numerous advantages. Watch the screencast to find out more!

Up next week: Specifying components with RSpec

Rspec is a framework for specifying behavior. Next week we’re gonna take a look at specifying single components of our application with RSpec. We’ll especially focus on how you can specify components in isolation from others with stubbing and mocking.

Thanks to Amrit Deep Dhungana who asked us on our Facebook page to talk about RSpec stubbing and mocking. Yes we can! And we love to.

Further readings:

Permalink

Bringing Continuous Deployment to everyone

  • Twitter
  • Facebook
  • HackerNews
  • Reddit
  • LinkedIn
  • Google Plus
  • Email
  • RSS
  • StumbleUpon
  • Tumblr

The Codeship Continuous Deployment Meetup
 
At Codeship we have a clear vision:

“Bring Continuous Deployment, the technology and process that powers innovation in some of the best and largest companies in the world, to every software developer. “

 
That’s why we talk at conferences. That’s why we hold meetups. That’s why we teach on this blog or write guest posts. And that’s why we put all our efforts into building the simplest, most intuitive and best product for Continuous Deployment out there: The Codeship.

Continuous Integration and Continuous Deployment

Our team has an inherent belief in agile software development. Continuous Integration and Continuous Deployment are perfect for enabling quick iterations and extremely fast feedback cycles. But not only are they great for software engineering, they also make a whole lot of sense and offer many advantages from a business perspective. This is why Continuous Deployment IS the way software AND products will be built in the future.

The Codeship Continuous Deployment Meetup

Picture taken by Sebastian Fung

Codeship’s Continuous Deployment meetup

Yesterday, May 30th 2013, we made one more decisive step into bringing Continuous Deployment to everyone. Together with Abby Fichtner (aka. the infamous @HackerChick) we organized a meetup in Boston’s Microsoft New England Research and Development Center to talk about Continuous Deployment. We invited some of the best engineers working in that space.
Just a plain old border – nothing to see here
Etsy – Dan Rowe

Dan Rowe from Etsy joined us talking about the processes him and his co-engineers are using in one of the most innovative and most respected companies from an engineering point of view nowadays. Etsy frequently blogs about their development process and their technical setup on their awesome CodeasCraft blog. Dan told us that you have to be confident in your system. But you will see the benefits very quickly. One being for example that every new engineer is able to deploy on their first day. He also gave great insights into how Etsy tests and deploys.

Just a plain old border – nothing to see here
GrabCAD – Amos Benninga

Amos Benninga is Chief Architect at former TechStars Boston 2011 company GrabCAD and explained what continuous deployment means for a team working in three different time zones. At his company every developer gets the power of Continuous Deployment from day one. And they use this power. He further talked about GrabCAD’s keymetrics and what their definition of “Getting started in 2 minutes” is.
Just a plain old border – nothing to see here
insightsquared – Ken Eimer

Ken Eimer from insightsquared told us about their 2-week-sprints and what it means for his company when a feature is “delivered”. He explained that getting code into production frequently and quickly is a major factor in making engineers happy. And happier engineers are better engineers. At insightsquared a feature is “done” when it’s verified and in production.
Just a plain old border – nothing to see here
It was awesome to see that the one thing these three great engineers, working for prospering and very successful companies in different spaces, had in common was Continuous Deployment. They may use tailor-made processes for their company’s specific needs, but they prove that Continuous Deployment can be implemented into every company. And every company should do it, as it makes them faster, better and happier. The advantages are not only clear to see for their engineers but also for their customers who for example can report bugs and see them resolved really quickly. Darragh Curran from Intercom touches upon that fact in his great blog post about shipping being your company’s heartbeat.

Conclusion

You might find it hard to start with continuous integration or don’t really know how to incorporate Continuous Deployment into your daily workflow but once you started you will immediately realize the benefits of it and how it will help creating a better product in the long run. We have seen the power of Continuous Deployment and we want to bring it to you. We thank all the speakers and everyone who attended our meetup. It really means a lot to us as it helps us making one more step towards our vision:

“Bring Continuous Deployment, the technology and process that powers innovation in some of the best and largest companies in the world, to every software developer. “

 
How do you develop your software and your products? Did you make the switch to Continuous Deployment? Let us know your stories in the comments so we all can learn from each other!
 
We uploaded some pictures of the event on our Facebook page. You can find them here.
I will leave you with this awesome sketchnote about the meetup by @iamctodd

Codeship Meetup sketchnote by C Todd Lombardo

Permalink

Testing Tuesday #7: Managing test data with factory girl

  • Twitter
  • Facebook
  • HackerNews
  • Reddit
  • LinkedIn
  • Google Plus
  • Email
  • RSS
  • StumbleUpon
  • Tumblr

This is the seventh Testing Tuesday episode. 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 the top 5 Cucumber best practices.


Generating and maintaining test data

When you write software tests, you usually need to get your application into a certain state by creating test data. This test data is the basis to run your tests on.

One possibility to create this test data is writing an SQL script. A better one is writing fixtures. But all static test data has a downside: maintainability.

Generating test data with factory girl

There are tools that make generating and maintaining test data easy. In this screencast I show you why using a test data generation tool makes sense. I introduce my favorite tool named factory_girl. It is written in Ruby, but there are libraries inspired by factory_girl for Python, PHP, Scala and JavaScript as well. You can find them below in the “Further readings” section.

Up next week: Integration & Unit testing in BDD

In next week’s Testing Tuesday #8 we’ll talk about integration and unit testing and how to use it in behavior driven development. We will meet our old friend Cucumber again and also introduce our new friend Rspec.

Further readings:

Permalink

Testing Tuesday #6: Top 5 Cucumber best practices

  • Twitter
  • Facebook
  • HackerNews
  • Reddit
  • LinkedIn
  • Google Plus
  • Email
  • RSS
  • StumbleUpon
  • Tumblr

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.


My personal best practices on how to use Cucumber

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? How can you reuse steps most efficiently? What are typical Cucumber smells?

Following I list 5 best practices that help us in our daily Cucumber life at Codeship.

1. Write declarative features

Scenarios should be written like a user would describe them. Beware of scenarios that only describe clicking links and filling in form fields, or of steps that contain code or CSS selectors. This is just another variant of programming, but certainly not a feature description.

Declarative features are vivid, concise and contain highly maintainable steps.

2. Insert a narrative

Narratives describe in about one sentence what a feature does. Typical narratives contain a benefit for the user, a role that needs the feature and the feature itself. Narratives are important to envision why you are implementing a feature in the first place. They also give a short overview of the feature so others get a rough understanding what it is about without reading the scenarios.

3. Avoid conjunctive steps

When you encounter a Cucumber step that contains two actions conjuncted with an “and”, you should probably break it into two steps. Sticking to one action per step makes your steps more modular and increases reusability. This is not a general rule though. There may be reasons for conjunctive steps. However, most of the time it’s best to avoid them.

4. Reuse step definitions

In Cucumber you can reuse steps in other steps. This comes in handy when a step extends another step’s behavior or defines a superior behavior that consists of multiple steps. You should try to reuse steps as often as possible. This will improve the maintainability of your app: If you need to change a certain behavior, you just need to change a single step definition.

5. Use backgrounds wisely

If you use the same steps at the beginning of all scenarios of a feature, put them into the feature’s Background. Background steps are run before each scenario. But take care that you don’t put too many steps in there as your scenarios may become hard to understand.


Up next week: Managing test data

In next week’s Testing Tuesday #7 we’ll talk about test data. What’s the best way to create test data? How can you keep test data maintainable when your application data model changes? If you’ve got some tips on test data management or you can recommend a good test data tool, please drop me a line!

Further readings:

Page 1 of 712345...Last »