8 Comments

• #1 by Josef on January 16, 2011 - 3:16 pm

  Quote

  

  Are you available for freelance projects? thanks.

• #2 by cowboycoded on January 16, 2011 - 7:37 pm

  Quote

  

  @Josef – At this time, I only work on my own startup projects.

• #3 by claudiob on January 19, 2011 - 10:25 pm

  Quote

  

  I found your question at http://stackoverflow.com/questions/4433347/ very relevant. I would like to know if you have somehow proceeded on that path and have some preliminary code available to share. I’m looking in that direction as well. Thanks.

• #4 by cowboycoded on January 20, 2011 - 8:34 pm

  Quote

  

  Some people thought I was nuts for suggesting that But I don’t think they really understand what I was trying to accomplish.

  I have been sidetracked with my business work in the last few weeks, so I havent had a chance to work on it much. I thought about it for a few days after I asked that question and I definitely want to make the language more natural in the steps… the examples I provided in that question are extremely verbose and they could be simplified. Initially I wanted to hook directly into Cucumber, but it would take me weeks to get a good feel for that code, since it is fairly complex. I am considering coding the generation directly in the step definitions. For instance:

  Given I want to create a “Widget”

  Given /^(?:|I )want to create a "([^"]*)"$/ do |model|
    if defined?(model.constantize)
      assert true
    else
      # generate model code and test this step again
    end
  end
  
  

  Basically the step runs its test as normal and if it fails it tries to generate the code and runs the step again.

  Its kindof a hack coding it directly into the step, but it would at least let me define the language and the generation code. Then when I have time to learn the Cucumber source, I can push it out to a plugin or extension.

  Let me know if you have any ideas or suggestions. I will get to this eventually, but it may be a few months before I start coding it.

• #5 by claudiob on January 21, 2011 - 2:38 am

  Quote

  

  Instead of having a new step

  Given I want to create a “Widget”

  why don’t you stick with the steps that you already have and that everybody uses, just interpreting their failures differently? I mean, take:

  Given a widget exists (or Given there is a Widget, etc…)

  If you run this step with cucumber and no model called Widget exists, then you get an error and proceed into the well-known fail->code->pass process.

  But if you run this step with… something else (e.g., cucumber with a particular flag that you may add), then not finding a Widget model would not raise an assertion, but would be interpreted as “Ah! This means the code NEEDS a Widget model, so I’m going to create one automatically.”
  And then the test would become green instantly.

  Now, the newly created Widget would have no fields. But if the step said:

  Given a widget with name “Colorizer”

  Then running… something else (e.g., cucumber with a particular flag that you may add) would interpret this as “Ah! I have a widget model but with no fields, and here the field ‘name’ is used, so I am going to automatically add that field to the Widget model!”.

  And so on… and not just with models, but also with views and controllers. For instance, say a successive step was:

  When I navigate to that widget’s page

  Then your “magic-powered” cucumber would interpret this as “Ah! The Widget model does not have any view yet, but here a ‘page’ view is referred, so I’m going to create a widget.show method in the controller and then a show template in the views!”.

  And on and on:

  Then I should see the widget name in the title

  Would be interpreted as “Ah! This page has no so I’m going to add one, and I’m going to fill it with the widget name”.

  In this way, you would not need people to rewrite their entire stories, you would just create a way to interpret them differently. And most importantly, you would keep things DRY, because you would not have to write steps that explicitly create models, instances, fields or views. It would all be implicit! What do you think?

• #6 by cowboycoded on January 21, 2011 - 2:12 pm

  Quote

  

  I am totally with you on this. This is almost exactly how I envisioned it working, aside from the language (I use a heavily modified version of the default web steps). I think the implicit idea is great.. I agree that using the steps that ship with cucumber would be the best starting point for this. I created a new project on github called “never_fails” and gave you access to the repo:

  https://github.com/cowboycoded/never_fails

  I created a test app with cucumber installed if you want to start experimenting with some code. For now, lets just modify the default web_steps.rb until I figure out a better setup for the gem. There is a helper file under the cuc support directory that extends World… we can put the majority of the code in there for now.

• #7 by Joe on August 26, 2011 - 12:14 am

  Quote

  

  Hi John,

  Just wonderwhy you made a shift from Java to RoR (Enterprise to agile). I am a Java developer for Oracle on some banking software implementation project and have got quite frustrated about the productivity and collaboration with offshore development centre (India). I feel like most of my time is wasted on process-laden activities. Did you feel the same before?

  Could you shed some light on how and where you managed to get private jobs to fund yourself when you first abandoned Java?

  Your advice is much appreciated. by the way, RoR rocks!

• #8 by cowboycoded on August 26, 2011 - 5:19 pm

  Quote

  

  Joe,

  I had a startup on the side (in php) while I was doing enterprise development and luckily it took off and I was able to do the startup fulltime. After 2 years with php, I found RoR and never looked back. At least where I live, there are a shortage of good RoR developers and plenty of demand from small to medium sized businesses. I would recommend joining your local ruby meetup group if there is one and you should be able to find the work if you talk to enough people.