Why instead of descriptors obvious doesn't use cucumber features?

[brianknapp]

Well, I'm not really sure they are trying to accomplish the same thing. The goal of descriptors was to give a shorthand way of writing use cases that would be able to generate a lot of boilerplate structure for you, including test structure so that you can get up and moving quickly and not be too bogged down in wiring.

I haven't used cucumber before, but my understanding is that it is a testing tool, not a code gen tool.

I suppose it would be possible to make the descriptors out of cucumber, but I don't know exactly how that would work. I'd love to see a pull request if you have any ideas.

[cored]

Well, yes you are right cucumber is a testing tool'; what I was referring to was to read the feature file and based anything that obvious needs from descriptor with that. A feature file is a set of scenario, same thing as a descriptor is a set of actions.

[brianknapp]

That sounds like a good idea, if you can do a gist or pull request with an example of how to pull out useful information from a feature file to generate the same things a descriptor does, I'd love to see it. A proof of concept even would be enough to get the ball rolling.

On Wed, Aug 21, 2013 at 11:00 AM, Rafael George notifications@github.comwrote:

Well, yes you are right cucumber is a testing tool'; what I was referring to was to read the feature file and based anything that obvious needs from descriptor with that. A feature file is a set of scenario, same thing as a descriptor is a set of actions.

— Reply to this email directly or view it on GitHubhttps://github.com/RetroMocha/obvious/issues/35#issuecomment-23028087 .

[cored]

Sounds good, will try to investigate about it; and make some sort of map between a descriptor and a feature file. I was thinking in just taking out the Scenarios as actions something like this

Feature: As a User I want to be able to list posts

   Scenario: List posts
      When I go to the list post page 
      Then I should see all the posts sorted by date

[safarista]

I don't think cucumber will play nice here. Too many dependencies/tools for a simple straightforward job. I'd keep it the way it is. Anywhere Cucumber can play, RSpec can play. It's best to keep it light and easy to write boilerplate descriptors generator. And to separate testing from code you are testing.

[brianknapp]

Perhaps a more interesting approach would be to be able to write descriptors as ruby code instead of as YAML. I chose yaml because it was close conceptually to how I thought of them, but it might be smarter/better/clearer to have a real ruby DSL for this.

On Fri, Aug 23, 2013 at 12:02 PM, Nelson Kelem notifications@github.comwrote:

I don't think cucumber will play nice here. Too many dependencies/tools for a simple straightforward job. I'd keep it the way it is. Anywhere Cucumber can play, RSpec can play. It's best to keep it light and easy to write boilerplate descriptors generator.

— Reply to this email directly or view it on GitHubhttps://github.com/RetroMocha/obvious/issues/35#issuecomment-23176901 .

[cored]

I suggested Cucumber or even just plain gherkin files, just because the tool is already there and is already well known; which implies another dependency that Brian won't maintain.

On 23 August 2013 14:51, Brian Knapp notifications@github.com wrote:

Perhaps a more interesting approach would be to be able to write descriptors as ruby code instead of as YAML. I chose yaml because it was close conceptually to how I thought of them, but it might be smarter/better/clearer to have a real ruby DSL for this.

On Fri, Aug 23, 2013 at 12:02 PM, Nelson Kelem notifications@github.comwrote:

I don't think cucumber will play nice here. Too many dependencies/tools for a simple straightforward job. I'd keep it the way it is. Anywhere Cucumber can play, RSpec can play. It's best to keep it light and easy to write boilerplate descriptors generator.

— Reply to this email directly or view it on GitHub< https://github.com/RetroMocha/obvious/issues/35#issuecomment-23176901> .

— Reply to this email directly or view it on GitHubhttps://github.com/RetroMocha/obvious/issues/35#issuecomment-23185442 .

Rafael George

[safarista]

The way I see it is this way: Obvious is one of the simplest, lightest dev-tools. I mainly use it to build business logic that is independent of frameworks like Rails etc. These frameworks change a lot. Their changes rarely define or change my business logic. Rather, they almost always break the app. I have to sometimes get into running apps to fix things that have nothing to do with the business but the framework. So I want to keep my business logic in Ruby as a gem or simply code that relies at most on Obvious and RSpec and plug persistence anywhere I want. And so far in my experience only Obvious allows me to do that.

I'd go with plain ruby for this or keep it as is with YML. If say I am going to extract the parts into a gem, then I need as fewer dependencies, if not none at all. I can deal with having deps that the gem require. I don't want dev-deps in the way. YML is already a native ruby lib.

Any dep' that is externally maintained is bound to change, and you dont want that dep defining your business logic. I just want frameworks out of the way and only when i need them.

Hope it makes sense. Been a long night.

[brianknapp]

@safarista I am 100% with you on this. I tend to avoid dependencies like the plague, even to the point of rewriting tests in minitest:spec so that I don't have an rspec dependency. Even a YAML dependency can be problematic if you are using something like Ruboto on Android (which I would avoid for now). Anyhow, if I end up redoing descriptors, they will very likely be done in a pure ruby DSL. I don't know when I will have time to do it, but as always I'm open to pull requests or gists if someone has a good idea and wants to prototype something.

@cored I like the suggestion of Cucumber or gherkin, but if I were to write it myself I'd likely make my own ruby DSL. If someone else can prototype an awesome version of descriptors using gherkin, I'm open to suggestion.