run/async commands

[AdrieanKhisbe]

syntactic visual suggar for command to be run synchronoulsy, or asynchronously

[AdrieanKhisbe]

draft in 481a5be, asnyc not yet commited

[AdrieanKhisbe]

@rylnd any remark, idea, suggestion about this? :)

[rylnd]

It would be helpful to see some examples for this feature, I'm not really understanding the use case.

[AdrieanKhisbe]

The point is to say explicitely that you are calling some function. This is mainly for test readability purposes.

If I take the following test:

describe "exit codes"
  shpec_cmd="$__/../bin/shpec"
  it "returns nonzero if any test fails"
      $shpec_cmd $__/etc/failing_example &> /dev/null
     assert unequal "$?" "0"
   end
  # ....

I would rewrite it this way:

describe "exit codes"
  shpec_cmd="$__/../bin/shpec"
  it "returns nonzero if any test fails"
     run $shpec_cmd $__/etc/failing_example &> /dev/null
     assert unequal "$?" "0"
   end
  # ....

We could and maybe should the same to replace a=b by assign a b

Following discussion #57 , what it enable us, is not to execute the code on some condition. (for instance, the pending flag)

[rylnd]

I like that this would solve the problem I mentioned here, but there are some issues:

1. It would require the test writer to write more code, adding a run to every non-assertion command
2. There's nothing ensuring that the test actually uses the run command, so the side effects can still be an issue in pending tests.

Making the user do extra work seems wrong. I want shpec to do that stuff under the hood.

I've been going back and forth about how and when to implement encapsulated tests: most of the outstanding issues are centered around that concept.

I believe that #16 is a better solution to the side-effect issue, if we can make it work.

@AdrieanKhisbe please let me know if there are other benefits to this feature that I've overlooked.

[AdrieanKhisbe]

the fact is that don't see how we could do thing instead of the user if he does not give us the end by calling a function we control.

by doing so we could then (by creating the appropriate logic in the run async assignfunctions), do the pending test, the housekeeping.

I see it in the same way that rspec that kindof forced user to put executing logic inside { proc } rather than directly in the test.

Beside that would push the user to write function instead of putting a x consecutive command in a test

it "Is a wunderfull test"
  run a "with some arg"
  run b 52
  run c 3 po
  run d 3
  run e uuhhh
  assert the ruth
end

replace it with

prepare_my_test(){
    a "with some arg"
    b 52             
    c 3 po           
    d 3              
    e uuhhh          
}
it "Is a wunderfull test"
  run prepare_my_test
  assert the truth
end

[AdrieanKhisbe]

I replemented this based on posix merge.

You can have a look on my branch https://github.com/AdrieanKhisbe/shpec/tree/features/improved-dsl

while doing It had some idea:

• we could easily add pending behavior? (as we already discussed)
• that would easily enable us to create a verbose mode! :)

I also made a clean command. that is just a rm. (rather to have run rm when I updated the existing specs).

@rylnd @hlangeveld @locochris, feedback welcome :)

[rylnd]

@AdrieanKhisbe could you open up a PR for that branch and reference this issue? It's much easier to review and discuss the code that way.