Where to start with TDD on a non Rails app

Testing
1

@benorenstein I am relatively new to testing, and I seem to be able to test Rails Apps pretty well.

However I am now writing a ruby app that will connect to a MySQL database using ActiveRecord to get all the image URL’s and then go into the directory’s they are located resize them and then I upload them to the server if they don’t already exist.

I am trying to do this using TDD but I am struggling on where to start.

What thought process do you go through to get started? What is the first thing I should test for to get started?

Any help is really appreciated.

2

I start pretty much all testing with an integration test. I focus on the high-level goal of the code I’m going to write.

If the goal is resized images on a server, I’d write a test that kicked off the process and then made some simple assertions about how the world should look.

Your exact example is complicated by the fact that you’re interacting with external services. Josh’s workshop, though Rails-focused, does cover how to deal with this scenario: Test-Driven Rails with RSpec and Capybara | Upcase Tutorials

3

To piggy back off of what @benorenstein said, a useful exercise would be to break your application into a series of high level use cases or services.

In the Rails context that you are used to, handling the use case for finding all images might look like this:

class ImagesController < ApplicationController
  def index
    @images = Image.all
    ...
  end
end

This could also be extracted to a service or use case object like this:

def index
  @images = FindImages.new(some_request_params).run
  ...
end

where FindImages would handle the interaction of the different parts of the system.

There are many different ways to name these objects but I think you get the gist. Such an object provides the context for interaction that is sometimes found in the controllers of Rails apps. It also acts as an entry point to actual application, allowing a CLI or Web interface to be easily wrapped around the usecases, and a nice entry point for an integration test.

As always, this is probably not the best solution, but could help alleviate the pain felt when initially straying from the comforting structure of Rails.