Bye!

Class methods mocking

Hum. Static’s bad, don’t do static, mkay? Well, not necessarily. The fact that you can test class methods like this makes them much more usable than they are in C#, where using static all over the place brings your design to the dumpster pretty quickly. Still, the use of class methods usually covers for underlying design flaws, so it’s a technical debt and you should evaulate what is convenient to do case by case.

The above snippet is powered by mocha, a mocking framework for ruby. It has a JMock-like syntax and it provides you all the usual tools.

mock()

creates a mock object. You can set expectations on a mock object with

mock_object.expects(:method_name)

and stubs with

mock_object.stubs(:method_name)

Expectations are verified at the end of the test: if you’ve set an expectation for :method_name and that method isn’t called on the mock object before the end of the test, that test will fail (no need to VerifyAllExpectations or such). Instead, stubs do not fail the test if not called.
So, in the following example:

if we remove the object.second call from the method run only the second test fill fail.

As seen before, you can set expectations and stubs not just on mocks but on any object, even class objects. Abusing of this feature, as to say in object = Object.new; object.expects(:method) ,  is probably not wise but as shown in the first snippet this allows testing of usually not testable situations.

You can force constraints on expectations using with(param_value) and you can return values with returns(value). For example, the following code:

mock_object = mock()
mock_object.expects(:get_capital).with('sweden').returns('stockholm')

Sets an expectation on mock_object for the method get_capital, the expectation is satisfied only if get_capital is called with the string 'sweden' and, if called that way, returns the string 'stockholm'. Of course you don’t need both clauses to be present togheter, mock_object.expects(:get_capital).with('sweden') and mock_object.expects(:get_capital).returns('stockholm') work just as expected. If you don’t set a return value for any given expectation/stub it will return nil.

stub_everything() returns a mock object that stubs every possible method call. The return value will always be nil.

More on mocha will be found on its documentation page.

what I do expect to happen here is userToPersist alone being saved in database after SubmitChanges. What happens instead is userToPersist AND user being saved.

Hundreds and hundreds of future mapping files to write aren’t gonna move me away a single step from NH until THIS is what i get from competitors…

We’re engineers, and we make machines work. You use the best tool for the job to do that. You don’t choose some pretty language [Ruby] that “brings back the joy of coding” or equivalent hippy shit.

And more:

C is the dominant language right now and probably for the distant future. It’s the lingua franca of computing. Nearly every server application worth a damn is written in C.

Well, the guy here maybe needs to chill out a bit but I think he’s right: C is here to stay. Planning to use anything else for a large project where performance is crucial is insane (Java and C#, you heard me ). C is a really powerful and valuable tool, and every developer should have at least some knowledge of it: I started out with C64 Basic, then Assembly for a long, long time, then lots of C, after that Java, VB, C# and then Ruby. I know people like Why are promoting Ruby as a learning language but honestly, I can’t really imagine someone with no knowledge of C writing good Ruby.

But probably in the 70′s somebody made similar statements, just replacing C with FORTRAN. Right now, C is the language. What about it in 10 years? I’m really, really surprised every time I read such statements: they make me feel like story never happened. No wonder Berlusconi is gonna win the elections with 70% of the votes next week.

And even if C is the best all-purpose tool we have now, what’s the point in using it even if the situation would allow a not-so performant but much more pleasant to use tool instead? Is there some kind of pride to gain in being miserable doing your job that I’m not seeing? Ruby performs like crap, but it’s a pleasure to work with. And 99% of the times nobody cares about performance.

All these things have been said countless times by people way more authoritative than I will ever be but it seems there’s still need to state them clear…

What if google releases a full fledged OS in a couple of years? Something that’s going to change the way we think about OS , the same way Wave will change our standards about messaging? What will Microsoft do then? Is it ready for the challenge?

I don’t really think so: there’s not been any real user experience innovation in OS since Xerox and Microsoft had all the time and resources in the world to think about something new and clever. It’s out there to see that they didn’t, and if Google really comes out with an OS i think it will be something Microsoft’s products can’t even compare to.

The only reason Microsoft is still alive and well is its privileged position in the OS market. Better for them if they start thinking about what to do next right now, or Google is gonna wipe them out.

I’m not really sure if that’s good or bad though.

Let’s create these dummy entities:

Entities

And now let’s register them the same way they did and see what happens when trying to resolve a Person:

As you can see Windsor actually “resolves” both Address and Job as if they were a dependency, setting both of them as a new instance! I don’t really think this is a bug but it’s totally not what I expected…

Having interfaces in between (so IPerson, IAddress and IJob) and then trying to resolve IPerson solves the “problem” (so I get a person with null Address and Job).

C#

public int Multiply(int firstFactor,int secondFactor)
{
      return firstFactor*secondFactor;
}

Ruby

def multiply(first_factor, second_factor)
   return first_factor*second_factor
end

What these methods are supposed to do is pretty straightforward. What they actually do, maybe not so.  What if you were to test both methods? What\how many tests would you write to make sure these methods behave as you expect?

Let’s take a look at the C# method. It takes two parameters (both int, so value types) and returns an integer. Relying on cyclomatic complexity to determine, for a given method, how many tests must be written is often uncorrect but let’s assume that it’s okay for this case, so one test that verifies the result for a given input might be enough.

What about the Ruby method? It takes two parameters and returns something. And the two parameters might be pretty much anything. How about testing this one? There’s no IFs so we might say that one test is still fine, or you might want to check parameters for correctness, or maybe make sure that who calls your method do it the way it’s supposed to. Either options (except the first but seriously, you’re not going for that one) requires extra effort in comparison to the C# approach.

About mocking:

C#

public Controller(IView view, IModel model)
{
      //some stuff happening here
}

And Ruby

def initialize(view, model)
      #some stuff happening here
end

Mocking view and model in C# requires some degree of IView = repo.CreateMock<IView>(). This relies on the IView interface, and you’ve got nothing like that in Ruby. You just mock methods instead. Mocha syntax:

def test_refresh_always_callRefreshOnView
   view = Mock()
   view.expects(:refresh)
   controller = Controller.new(view,Stub())
   controller.refresh
end

No need of VerifyAllExpectations() or such: this fails automatically if refresh is not invoked on the view object.

A similar problem arises when using IoC containers: you’ve got no interface to resolve. More about this later.

After creating a new Glade project some windows will pop up. Among them will be the palette window and the properties window : the first one allows you to create new widget, so click on the upper left button to create a window widget, then add a button to the newly created window by selecting the button widget and then left-click on the window body.

Palette window

Now it’s time to look at the property window. By selecting the button that you craeted the property window will show all its properties. Select the signals tab and then click on the ellipse on the lower left of the window: that will show a dialog containing all the button’s available signals. Double click on clicked, then click add on the signals window.

Signals window

Now save the project and close the Glade designer. You will see that Glade created two files in the folder you chose: the one that cares to us it the yourprojectname.glade file. Now open a terminal at the folder location and type in:

ruby-glade-create-template yourprojectname.glade > yourrubyfile.rb

Where yourrubyfile is a filename of your choice. This will create a new yourrubyfile.rb that looks like:

#!/usr/bin/env ruby
#
# This file is gererated by ruby-glade-create-template 1.1.4.
#
require 'libglade2'

class yourrubyfileGlade
  include GetText

  attr :glade

  def initialize(path_or_data, root = nil, domain = nil, localedir = nil, flag = GladeXML::FILE)
    bindtextdomain(domain, localedir, nil, "UTF-8")
    @glade = GladeXML.new(path_or_data, root, domain, localedir, flag) {|handler| method(handler)}

  end

  def on_button1_clicked(widget)
    puts "on_button1_clicked() is not implemented yet."
  end
end

# Main program
if __FILE__ == $0
  # Set values as your own application.
  PROG_PATH = "yourprojectname.glade"
  PROG_NAME = "YOUR_APPLICATION_NAME"
  Project1Glade.new(PROG_PATH, nil, PROG_NAME)
  Gtk.main
end

Running the file will display the window you created and clicking on the button will execute whatever logic you’ve put inside the on_button1_clicked method.

Let me explain. It seems that just a little share of the so-called programmers can actually program. But there’s more : even among this elite the difference between the best and the worst are of orders of magnitude. And worse : you can’t really learn it.

So, what the hell? There’s a huge amount of software that needs to be written out there, who’s gonna do that? Just the elites from the elite? Wait, here’s the solution: Methodology! You don’t need the gift, just blindly and faithfully follow the Instructions and everything’s fine! What a breakthrough!

And I’m serious about that. I’ve seen that in action, it costs – a LOT – in terms of productivity but you can actually make people that have no clue about programming building quality software. Take a Methodology and enforce it brutally: there’s no “maybe i’m doing this my way” or “let’s just patch it up for the next release”. Everything must be done by the book. It works. And i think it’s not a bad thing, of course unless Jeff and Joel are right and quality really doesn’t matter : but i like to think that’s not true – even knowing that i’m probably wrong.