acts as human

leomayleomay's blog.

Quotes_on_mock

| Comments

Making a Mockery of TDD

mocked methods with defined return values are often (though not always) a warning sign. I find most of my test doubles fall into one of two categories: stubs with no behavior, just a return value; and mocks that expect a certain method call, but define no return value (no ‘and_return()’, in RSpec terms).

Links

| Comments

Making ActiveRecord Models Thin

Something that always bothers me in a typical Rails application is the lack of a well defined model API. Your Domain Model should have an interface to every action your application should be able to perform. If you have an online shop where a user can buy a product then with a well-written Rails application you should be able to fire up the console and be able to easily perform this operation. If it’s not so simple then you probably want to think about your model implementation again.

Links

| Comments

What was a Classic Tester Became a Mockist…

I have a comment about which programming artifacts should be mocked. It is highly recommended to not mock methods of the same object. Mocking tdd is about collaboration BETWEEN objects/roles. It is not about implementation details of the “system under test”.

Simplifying your Ruby on Rails code: Presenter pattern, cells plugin

you should not do any manipulations on models in presenters. They only decorate models with helper methods to be used inside controllers or views, nothing else.

The Secret to Rails OO Design

Extracting domain objects is good. They keep your tests fast, your code small, and make it easier to change things later.

How to Learn New Stuff

| Comments

We are all getting older and older (except you are Benjamin Button), and have you ever felt it’s getting more and more difficult to wrap your head around a new thing? I do, I am learning myself iOS development recently, and I thought the syntax is weird, the memory management is really hard to grasp. Maybe it’s because I’m not a talented programmer, I said maybe. The real reason it’s getting harder and harder is I’m too biased, I’m full of Ruby and Rails. If I were a cup, then I’m full, I can not take any more from the outside world unless I pour the stuff inside me out, totally out, forget what you’ve known, get out of the sweet spot. Yeah, that’s it.

Class Oriented Programming vs. Object Oriented Programming

| Comments

We usually mix a module into a class definition to make the Class hold 1+ responsibilities,

Class Oriented Programming (cop.rb) 
1
2
3
4
5
6
7
8
9
10
11
12
13
14

# user.rb
class User < ActiveRecord::Base
  include BuyerLogic
end

# shopping_carts_controller.rb
class ShoppingCartsController < ApplicationController
  before_filter :login_required

  def add_to_cart
    @product = Product.find(params[:product_id])
    @current_user.add_to_cart(@product, params[:quantity])
  end
end

While this is a pretty common programming practice for almost every Rails programmer (including me), we are doing it WRONG. We are doing CLASS ORIENTED PROGRAMMING but the OBJECT ORIENTED PROGRAMMING, you can tell the difference between COP (Class Oriented Programming) and OOP (Object Oriented Programming) via the following snippet.

Object Oriented Programming (oop.rb) 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# user.rb
class User < ActiveRecord::Base
end

# shopping_carts_controller.rb
class ShoppingCartsController < ApplicationController
  before_filter :login_required

  def add_to_cart
    @current_user.extend BuyerLogic

    @product = Product.find(params[:product_id])
    @current_user.add_to_cart(@product, params[:quantity])
  end
end

The difference is pretty obvious, it’s the @current_user, which is an instance (object), extends the BuyerLogic, not the User, which is a class include the BuyerLogic. While you may say it’s the same logic they are trying to achieve, correct, but we claim we are doing Object Oriented Programming, right? Then we should let the object but the class hold the responsibility.

The pattern described above is called DCI, it’s meant to keep our promise to the SRP.

DCI suggests that we keep our core model classes very thin. Zero logic, only data, if anything. The logic/behaviour should be kept in roles. In Ruby we can nicely use mixins for that.

  • http://andrzejonsoftware.blogspot.com/2011/02/dci-and-rails.html

  • http://saturnflyer.com/blog/jim/2011/10/04/oop-dci-and-ruby-what-your-system-is-vs-what-your-system-does/