Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add/before block #52

Open
AdrieanKhisbe opened this issue Mar 10, 2015 · 3 comments
Open

add/before block #52

AdrieanKhisbe opened this issue Mar 10, 2015 · 3 comments

Comments

@AdrieanKhisbe
Copy link
Collaborator

add/before block to regroupe setUp or tearDown code.

(should see if either false block, or function)

draft in 481a5be

@AdrieanKhisbe AdrieanKhisbe added this to the Extra language features 0.2 milestone Mar 10, 2015
@AdrieanKhisbe
Copy link
Collaborator Author

forget about last draft

Best way to realise this would be to use after and before functions.

  • They should be invoke for each test
  • can be redefined between test
  • shall stay in describe scope

any suggestion on this _specification?_ (before I work on implementation)

@hlangeveld
Copy link
Collaborator

On 04/26/15 16:09, Adriean Khisbe wrote:

/forget about last draft/

Best way to realise this would be to use |after| and |before| functions.

  • They should be invoke for each test
  • can be redefined between test
  • shall stay in describe scope

/any suggestion on this /specification/?/ (before I work on implementation)

I guess you would just define the two functions, and let the framework check
for their existence and invoke them, so you don't have to refer to them in the
tests themselves?

What about |setup| and |teardown|? Those are conventional names for such functions.
Names like |before| and |after| don't appear to have any relation to each other.
The name |teardown| at least suggests that it cleans up whatever |setup| left behind.

Flip side: There's no guarantee that |setup| and |teardown| actually do anything like that.
It's still the responsibility of the test writers to make it so.

By whatever name, this could be useful.

Cheers,
Henk

@AdrieanKhisbe
Copy link
Collaborator Author

I suggested after and before since we going for integration, rshpec like terminology.

To have some scope I was rather thinking that the describe would set an empty function. (to be more refined if we want the parent describe's to affect the child describes), and that the call would be automatically made by respectively it and end

good week start :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants