Strange behavior
14 views
Skip to first unread message
DChenBecker
Aug 13, 2010, 1:37:34 PM8/13/10
to specs-users
I have a spec with three clauses in it. I've used setSequential() to
make sure they run in order because they do operations on a DB.
Unfortunately, it seems that the clauses get run multiple times (in
order, at least), which makes some of the clauses fail because row
counts don't match up. I added a simple println at the start of each
clause just to record and this is what I see:
running add users
running add users
running retrieve users
running delete users
running add users
running retrieve users
running delete users
The output I would expect would be:
running add users
running retrieve users
running delete users
It actually would work as-is if it weren't for the fact that the "Add
user" clause gets run twice in a row.
I'm a newb when it comes to writing specs, so am I doing something
completely wrong, or misunderstanding how specs operates?
Thanks,
Derek
make sure they run in order because they do operations on a DB.
Unfortunately, it seems that the clauses get run multiple times (in
order, at least), which makes some of the clauses fail because row
counts don't match up. I added a simple println at the start of each
clause just to record and this is what I see:
running add users
running add users
running retrieve users
running delete users
running add users
running retrieve users
running delete users
The output I would expect would be:
running add users
running retrieve users
running delete users
It actually would work as-is if it weren't for the fact that the "Add
user" clause gets run twice in a row.
I'm a newb when it comes to writing specs, so am I doing something
completely wrong, or misunderstanding how specs operates?
Thanks,
Derek
Kris Nuttycombe
Aug 13, 2010, 2:33:33 PM8/13/10
to specs...@googlegroups.com
I've found that you can only have a single "my system" should {} block
in a Specification. If you create an outer 'should' block, and change
the inner blocks to use 'in' or '>>' you won't get the multiple runs.
in a Specification. If you create an outer 'should' block, and change
the inner blocks to use 'in' or '>>' you won't get the multiple runs.
Kris
> --
> You received this message because you are subscribed to the Google Groups "specs-users" group.
> To post to this group, send email to specs...@googlegroups.com.
> To unsubscribe from this group, send email to specs-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/specs-users?hl=en.
>
>
Derek Chen-Becker
Aug 13, 2010, 2:50:30 PM8/13/10
to specs...@googlegroups.com
If I understand what you're saying then I think I'm already doing that. Here's the code in question:
http://gist.github.com/523347
Does that look right?
http://gist.github.com/523347
Does that look right?
etorreborre
Aug 13, 2010, 8:11:21 PM8/13/10
to specs-users
Hi Derek and Kris,
I'm going to investigate this during the week-end but my laptop is
dead for now, I need to setup a replacement :-(
Derek, the issue you're observing may be a result of running each
example in isolation by cloning the specification.
Maybe what you can try, until I have a look at it, is to add
shareVariables() to keep the whole execution in the
same specification effectively sharing the local variables.
Eric.
On Aug 14, 4:50 am, Derek Chen-Becker <dchenbec...@gmail.com> wrote:
> If I understand what you're saying then I think I'm already doing that.
> Here's the code in question:
>
> http://gist.github.com/523347
>
> Does that look right?
>
> On Fri, Aug 13, 2010 at 12:33 PM, Kris Nuttycombe <kris.nuttyco...@gmail.com
> > specs-users...@googlegroups.com<specs-users%2Bunsubscribe@googlegr oups.com>
> > .
> > .
I'm going to investigate this during the week-end but my laptop is
dead for now, I need to setup a replacement :-(
Derek, the issue you're observing may be a result of running each
example in isolation by cloning the specification.
Maybe what you can try, until I have a look at it, is to add
shareVariables() to keep the whole execution in the
same specification effectively sharing the local variables.
Eric.
On Aug 14, 4:50 am, Derek Chen-Becker <dchenbec...@gmail.com> wrote:
> If I understand what you're saying then I think I'm already doing that.
> Here's the code in question:
>
> http://gist.github.com/523347
>
> Does that look right?
>
>
>
>
> > wrote:
> > I've found that you can only have a single "my system" should {} block
> > in a Specification. If you create an outer 'should' block, and change
> > the inner blocks to use 'in' or '>>' you won't get the multiple runs.
>
> > Kris
>
> > On Fri, Aug 13, 2010 at 11:37 AM, DChenBecker <dchenbec...@gmail.com>
>
>
> > wrote:
> > I've found that you can only have a single "my system" should {} block
> > in a Specification. If you create an outer 'should' block, and change
> > the inner blocks to use 'in' or '>>' you won't get the multiple runs.
>
> > Kris
>
> > .
> > > For more options, visit this group at
> >http://groups.google.com/group/specs-users?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "specs-users" group.
> > To post to this group, send email to specs...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > specs-users...@googlegroups.com<specs-users%2Bunsubscribe@googlegr oups.com>
> >http://groups.google.com/group/specs-users?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "specs-users" group.
> > To post to this group, send email to specs...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > .
Derek Chen-Becker
Aug 14, 2010, 12:40:24 AM8/14/10
to specs...@googlegroups.com
Yeah, I suspected that. Turning on shareVariables() makes it work as I expected. While I understand the logic behind isolating the tests, I would argue that explicitly configuring a set of clauses to be run in sequence implies a dependence between them.
Derek
Derek
To unsubscribe from this group, send email to specs-users...@googlegroups.com.
etorreborre
Aug 15, 2010, 9:25:12 AM8/15/10
to specs-users
Actually "setSequential" and "shareVariables" were born in 2 different
contexts. "setSequential" came from the need to have examples being
executed right away in a LiterateSpecification (still experimental) in
order to display some resulting state in the following text. On the
other hand, "shareVariables" came from the need to avoid specs default
mode where local variables are reinitialized as a facility when
executing the tests.
So effectively "shareVariables" also means "setSequential" because if
you allow side effects to happen, the order in which they happen must
be well defined. Well,... unless you don't care, which must be also
possible but I fail to see a useful test/specification situation were
that would be the case.
Now about the specification in your gist, you can wonder if the first
and second examples are not redundant because there's no way to know
if persisting worked ok unless you do a find. This leaves us with
essentially 2 examples where you could factor out the creation of the
2 users as a doFirst action, to setup the system and one example
specifying the find, the other one doing the delete. I'm not saying at
all that's *the* way to do it, just showing another option.
That being said, in the example you're showing you shouldn't have to
use "setSequential" because examples are executed in order anyway. And
in any case, you should not observe any repetition and I need to
investigate that. Which runner are you using? Maven, sbt?
Eric.
contexts. "setSequential" came from the need to have examples being
executed right away in a LiterateSpecification (still experimental) in
order to display some resulting state in the following text. On the
other hand, "shareVariables" came from the need to avoid specs default
mode where local variables are reinitialized as a facility when
executing the tests.
So effectively "shareVariables" also means "setSequential" because if
you allow side effects to happen, the order in which they happen must
be well defined. Well,... unless you don't care, which must be also
possible but I fail to see a useful test/specification situation were
that would be the case.
Now about the specification in your gist, you can wonder if the first
and second examples are not redundant because there's no way to know
if persisting worked ok unless you do a find. This leaves us with
essentially 2 examples where you could factor out the creation of the
2 users as a doFirst action, to setup the system and one example
specifying the find, the other one doing the delete. I'm not saying at
all that's *the* way to do it, just showing another option.
That being said, in the example you're showing you shouldn't have to
use "setSequential" because examples are executed in order anyway. And
in any case, you should not observe any repetition and I need to
investigate that. Which runner are you using? Maven, sbt?
Eric.
Derek Chen-Becker
Aug 16, 2010, 1:36:26 PM8/16/10
to specs...@googlegroups.com
Comments inline:
On Sun, Aug 15, 2010 at 7:25 AM, etorreborre <etorr...@gmail.com> wrote:
Actually "setSequential" and "shareVariables" were born in 2 different
contexts. "setSequential" came from the need to have examples being
executed right away in a LiterateSpecification (still experimental) in
order to display some resulting state in the following text. On the
other hand, "shareVariables" came from the need to avoid specs default
mode where local variables are reinitialized as a facility when
executing the tests.
So effectively "shareVariables" also means "setSequential" because if
you allow side effects to happen, the order in which they happen must
be well defined. Well,... unless you don't care, which must be also
possible but I fail to see a useful test/specification situation were
that would be the case.
Thanks, this actually clears up some misunderstanding I had about the way the specs initialized and ran.
Now about the specification in your gist, you can wonder if the first
and second examples are not redundant because there's no way to know
if persisting worked ok unless you do a find. This leaves us with
essentially 2 examples where you could factor out the creation of the
2 users as a doFirst action, to setup the system and one example
specifying the find, the other one doing the delete. I'm not saying at
all that's *the* way to do it, just showing another option.
I see your point, but in this particular case, the insert clause is there because I had a regression in a previous version where the second insert wasn't working properly, so in my mind it really is a test of proper insertions.
That being said, in the example you're showing you shouldn't have to
use "setSequential" because examples are executed in order anyway. And
in any case, you should not observe any repetition and I need to
investigate that. Which runner are you using? Maven, sbt?
It happens when I run either. I can provide a full SBT/Maven project for you to run if that would help you.
Derek
To unsubscribe from this group, send email to specs-users...@googlegroups.com.
etorreborre
Aug 16, 2010, 5:24:23 PM8/16/10
to specs-users
Yes Derek send me a full project showing the issue (or even better a
small one :-)).
small one :-)).
Derek Chen-Becker
Aug 16, 2010, 6:30:10 PM8/16/10
to specs...@googlegroups.com
Hmmm. On a guess I moved over to Specs 1.6.5 and Scala 2.8.0 from Specs 1.6.2.2 (the latest I could find for 2.7.7) and now the issue doesn't occur anymore. Was this something you might have fixed in the interim? Do you have plans to release 1.6.5 for Scala 2.7.7?
Thanks,
Derek
Thanks,
Derek
To unsubscribe from this group, send email to specs-users...@googlegroups.com.
etorreborre
Aug 16, 2010, 7:07:56 PM8/16/10
to specs-users
Hmm, that's supposed to be the same thing, with the same fixes
1.6.2.2 is for scala 2.7.7
1.6.5 is for scala 2.8.0
And now that 2.8.0 is out, my plan was to go on fixing things on the
2.8.0 mostly and refactoring on that branch also.
Maintaining refactorings on 2 different scala branches would be too
tedious so I think I will mostly backport fixes on demand.
So if you're back, at some point, to 2.7.7 and you still have this
issue, please send me your project so that I can find a relevant fix.
Thanks,
Eric
1.6.2.2 is for scala 2.7.7
1.6.5 is for scala 2.8.0
And now that 2.8.0 is out, my plan was to go on fixing things on the
2.8.0 mostly and refactoring on that branch also.
Maintaining refactorings on 2 different scala branches would be too
tedious so I think I will mostly backport fixes on demand.
So if you're back, at some point, to 2.7.7 and you still have this
issue, please send me your project so that I can find a relevant fix.
Thanks,
Eric
Derek Chen-Becker
Aug 16, 2010, 10:23:13 PM8/16/10
to specs...@googlegroups.com
OK, per your explanation on setSequential and shareVariables, I did some further testing and I've isolated some things (a tiny bit). In my code, if I don't specify any special handling, the test works fine:
"EntityManager" should {
"Add users" in {
...
if I explicitly set shareVariables, it also runs fine:
"EntityManager" should {
shareVariables()
"Add users" in {
...
if I do both setSequential and shareVariables (in either order), it runs fine:
"EntityManager" should {
setSequential()
shareVariables()
"Add users" in {
-or-
"EntityManager" should {
shareVariables()
setSequential()
"Add users" in {
However, if I set only setSequential, it fails:
"EntityManager" should {
setSequential()
"Add users" in {
I get the same behavior under both Specs 1.6.2.2 and 1.6.5. Granted, now I understand that I don't even need to use setSequential, but it still seems odd that the tests run multiple times if I do use it. I've attached a self-contained test-case.
Derek
"EntityManager" should {
"Add users" in {
...
if I explicitly set shareVariables, it also runs fine:
"EntityManager" should {
shareVariables()
"Add users" in {
...
if I do both setSequential and shareVariables (in either order), it runs fine:
"EntityManager" should {
setSequential()
shareVariables()
"Add users" in {
-or-
"EntityManager" should {
shareVariables()
setSequential()
"Add users" in {
However, if I set only setSequential, it fails:
"EntityManager" should {
setSequential()
"Add users" in {
I get the same behavior under both Specs 1.6.2.2 and 1.6.5. Granted, now I understand that I don't even need to use setSequential, but it still seems odd that the tests run multiple times if I do use it. I've attached a self-contained test-case.
Derek
To unsubscribe from this group, send email to specs-users...@googlegroups.com.
etorreborre
Aug 17, 2010, 7:05:53 PM8/17/10
to specs-users
Thanks for the small self-contained project.
I get it now. Your example shows 2 things:
- setSequential should definitely imply shareVariables because if
examples are executed as soon as they are met, there's no way we can
duplicate the specification to execute them with their own set of
'fresh' variables.
This is what's causing the duplication you've seen and I'm going to
fix that.
- setSequential should have been left apart, with
LiterateSpecification where is was created.
For the future work on specs I think that it will make sense to
clarify 2 styles of specifications:
- "declarative" where the initial local variables are not shared so
that examples are independent
- "narrative" where the examples are telling a "story", building on
each other resulting state like in your database example
E.
> ...
>
> read more »
>
> specsDup.tgz
> 4KViewDownload
I get it now. Your example shows 2 things:
- setSequential should definitely imply shareVariables because if
examples are executed as soon as they are met, there's no way we can
duplicate the specification to execute them with their own set of
'fresh' variables.
This is what's causing the duplication you've seen and I'm going to
fix that.
- setSequential should have been left apart, with
LiterateSpecification where is was created.
For the future work on specs I think that it will make sense to
clarify 2 styles of specifications:
- "declarative" where the initial local variables are not shared so
that examples are independent
- "narrative" where the examples are telling a "story", building on
each other resulting state like in your database example
E.
>
> read more »
>
> specsDup.tgz
> 4KViewDownload
Derek Chen-Becker
Aug 17, 2010, 8:00:07 PM8/17/10
to specs...@googlegroups.com
That sounds great! I especially like the distinction between narrative and declaritive specs, since I do have some specs where the clauses are independent. I don't know if specs does it already, but parallel execution of declaritive specs would be quite nice. Thanks for the help!
Derek
To unsubscribe from this group, send email to specs-users...@googlegroups.com.
Derek
etorreborre
Aug 19, 2010, 8:07:29 PM8/19/10
to specs-users
It took me more time than expected but I've done this modification in
the latest 1.6.6-SNAPSHOT:
http://nexus.scala-tools.org/content/repositories/snapshots/org/scala-tools/testing/specs_2.8.0/1.6.6-SNAPSHOT
So now setSequential => shareVariables
Please all check that there's no unwanted regression in your
specifications,
Thanks.
On Aug 18, 10:00 am, "Derek Chen-Becker" <dchenbec...@gmail.com>
wrote:
>
> > OK, per your explanation on setSequential and shareVariables, I did some
>
> > further testing and I've isolated some things (a tiny bit). In my code, if I
>
> > don't specify any special handling, the test works fine:
>
> >
>
> > "EntityManager" should {
>
> > "Add users" in {
>
> > ...
>
> >
>
> > if I explicitly set shareVariables, it also runs fine:
>
> >
>
> > "EntityManager" should {
>
> > shareVariables()
>
> > "Add users" in {
>
> > ...
>
> >
>
> > if I do both setSequential and shareVariables (in either order), it runs
>
> > fine:
>
> >
>
> > "EntityManager" should {
>
> > setSequential()
>
> > shareVariables()
>
> > "Add users" in {
>
> >
>
> > -or-
>
> >
>
> > "EntityManager" should {
>
> > shareVariables()
>
> > setSequential()
>
> > "Add users" in {
>
> >
>
> > However, if I set only setSequential, it fails:
>
> >
>
> > "EntityManager" should {
>
> > setSequential()
>
> > "Add users" in {
>
> >
>
> > I get the same behavior under both Specs 1.6.2.2 and 1.6.5. Granted, now I
>
> > understand that I don't even need to use setSequential, but it still seems
>
> > odd that the tests run multiple times if I do use it. I've attached a
>
> > self-contained test-case.
>
> >
>
> > Derek
>
> >
>
> >
>
> >
>
> > On Mon, Aug 16, 2010 at 5:07 PM, etorreborre <etorrebo...@gmail.com> wrote:
>
> > > Hmm, that's supposed to be the same thing, with the same fixes
>
> >
>
> > > 1.6.2.2 is for scala 2.7.7
>
> > > 1.6.5 is for scala 2.8.0
>
> >
>
> > > And now that 2.8.0 is out, my plan was to go on fixing things on the
>
> > > 2.8.0 mostly and refactoring on that branch also.
>
> > > Maintaining refactorings on 2 different scala branches would be too
>
> > > tedious so I think I will mostly backport fixes on demand.
>
> >
>
> > > So if you're back, at some point, to 2.7.7 and you still have this
>
> > > issue, please send me your project so that I can find a relevant fix.
>
> >
>
> > > Thanks,
>
> >
>
> > > Eric
>
> >
>
> > > On Aug 17, 8:30 am, Derek Chen-Becker <dchenbec...@gmail.com> wrote:
>
> > > > Hmmm. On a guess I moved over to Specs 1.6.5 and Scala 2.8.0 from Specs
>
> > > > 1.6.2.2 (the latest I could find for 2.7.7) and now the issue doesn't
>
> > > occur
>
> > > > anymore. Was this something you might have fixed in the interim? Do you
>
> > > have
>
> > > > plans to release 1.6.5 for Scala 2.7.7?
>
> >
>
> > > > Thanks,
>
> >
>
> > > > Derek
>
> >
>
> > > > On Mon, Aug 16, 2010 at 3:24 PM, etorreborre <etorrebo...@gmail.com>
>
> > > wrote:
>
> > > > > Yes Derek send me a full project showing the issue (or even better a
>
> > > > > small one :-)).
>
> >
>
> > > > > On Aug 17, 3:36 am, Derek Chen-Becker <dchenbec...@gmail.com> wrote:
>
> > > > > > Comments inline:
>
> >
>
> > > > > > On Sun, Aug 15, 2010 at 7:25 AM, etorreborre <etorrebo...@gmail.com>
>
> > > > > wrote:
>
> > > > > > > Actually "setSequential" and "shareVariables" were born in 2
>
> > > different
>
> > > > > > > contexts. "setSequential" came from the need to have examples being
>
> > > > > > > executed right away in a LiterateSpecification (still experimental)
>
> > > in
>
> > > > > > > order to display some resulting state in the following text. On the
>
> > > > > > > other hand, "shareVariables" came from the need to avoid specs
>
> > > default
>
> > > > > > > mode where local variables are reinitialized as a facility when
>
> > > > > > > executing the tests.
>
> >
>
> > > > > > > So effectively "shareVariables" also means "setSequential" because
>
> > > if
>
> > > > > > > you allow side effects to happen, the order in which they happen
>
> > > must
>
> > > > > > > be well defined. Well,... unless you don't care, which must be also
>
> > > > > > > possible but I fail to see a useful test/specification situation
>
> > > were
>
> > > > > > > that would be the case.
>
> >
>
> > > > > > Thanks, this actually clears up some misunderstanding I had about the
>
> > > way
>
> > > > > > the specs initialized and ran.
>
> >
>
> > > > > > > Now about the specification in your gist, you can wonder if the
>
> > > first
>
> > > > > > > and second examples are not redundant because there's no way to
>
> > > know
>
> > > > > > > if persisting worked ok unless you do a find. This leaves us with
>
> > > > > > > essentially 2 examples where you could factor out the creation of
>
> > > the
>
> > > > > > > 2 users as a doFirst action, to setup the system and one example
>
> > > > > > > specifying the find, the other one doing the delete. I'm not saying
>
> > > at
>
> > > > > > > all that's *the* way to do it, just showing another option.
>
> >
>
> > > > > > I see your point, but in this particular case, the insert clause is
>
> > > there
>
> > > > > > because I had a regression in a previous version where the second
>
> > > insert
>
> > > > > > wasn't working properly, so in my mind it really is a test of proper
>
> > > > > > insertions.
>
> >
>
> > > > > > > That being said, in the example you're showing you shouldn't have
>
> > > to
>
> > > > > > > use "setSequential" because examples are executed in order anyway.
>
> > > And
>
> > > > > > > in any case, you should not observe any repetition and I need to
>
> > > > > > > investigate that. Which runner are you using? Maven, sbt?
>
> >
>
> > > > > > It happens when I run either. I can provide a full SBT/Maven project
>
> > > for
>
> > > > > you
>
> > > > > > to run if that would help you.
>
> >
>
> > > > > > Derek
>
> >
>
> > > > > > > Eric.
>
> >
>
> > > > > > > On Aug 14, 2:40 pm, Derek Chen-Becker <dchenbec...@gmail.com>
>
> > > wrote:
>
> > > > > > > > Yeah, I suspected that. Turning on shareVariables() makes it work
>
> > > as
>
> > > > > I
>
> > > > > > > > expected. While I understand the logic behind isolating the
>
> > > tests, I
>
> > > > > > > would
>
> > > > > > > > argue that explicitly configuring a set of clauses to be run in
>
> > > > > sequence
>
> > > > > > > > implies a dependence between them.
>
> >
>
> > > > > > > > Derek
>
> >
>
> > > > > > > > On Fri, Aug 13, 2010 at 6:11 PM, etorreborre <
>
> > > etorrebo...@gmail.com>
>
> > > > > > > wrote:
>
> > > > > > > > > Hi Derek and Kris,
>
> >
>
> > > > > > > > > I'm going to investigate this during the week-end but my laptop
>
> > > is
>
> > > > > > > > > dead for now, I need to setup a replacement :-(
>
> >
>
> > > > > > > > > Derek, the issue you're observing may be a result of running
>
> > > each
>
> > > > > > > > > example in isolation by cloning the specification.
>
> > > > > > > > > Maybe what you can try, until I have a look at it, is to add
>
> > > > > > > > > shareVariables() to keep the whole execution in the
>
> > > > > > > > > same specification effectively sharing the local variables.
>
> >
>
> > > > > > > > > Eric.
>
> >
>
> > > > > > > > > On Aug 14, 4:50 am, Derek Chen-Becker <dchenbec...@gmail.com>
>
> > > > > wrote:
>
> > > > > > > > > > If I understand what you're saying then I think I'm already
>
> > > doing
>
> > > > > > > that.
>
> > > > > > > > > > Here's the code in question:
>
> >
>
> > > > > > > > > >http://gist.github.com/523347
>
> >
>
> > > > > > > > > > Does that look right?
>
> >
>
> > > > > > > > > > On Fri, Aug 13, 2010 at 12:33 PM, Kris Nuttycombe <
>
> > > > ...
>
> read more »
the latest 1.6.6-SNAPSHOT:
http://nexus.scala-tools.org/content/repositories/snapshots/org/scala-tools/testing/specs_2.8.0/1.6.6-SNAPSHOT
So now setSequential => shareVariables
Please all check that there's no unwanted regression in your
specifications,
Thanks.
On Aug 18, 10:00 am, "Derek Chen-Becker" <dchenbec...@gmail.com>
wrote:
> That sounds great! I especially like the distinction between narrative and declaritive specs, since I do have some specs where the clauses are independent. I don't know if specs does it already, but parallel execution of declaritive specs would be quite nice. Thanks for the help!
>
> Derek
>
>
> Derek
>
> On Aug 17, 2010 5:05 PM, etorreborre <etorrebo...@gmail.com> wrote:
>
> Thanks for the small self-contained project.
>
> I get it now. Your example shows 2 things:
>
> - setSequential should definitely imply shareVariables because if
>
> examples are executed as soon as they are met, there's no way we can
>
> duplicate the specification to execute them with their own set of
>
> 'fresh' variables.
>
> This is what's causing the duplication you've seen and I'm going to
>
> fix that.
>
> - setSequential should have been left apart, with
>
> LiterateSpecification where is was created.
>
> For the future work on specs I think that it will make sense to
>
> clarify 2 styles of specifications:
>
> - "declarative" where the initial local variables are not shared so
>
> that examples are independent
>
> - "narrative" where the examples are telling a "story", building on
>
> each other resulting state like in your database example
>
> E.
>
> On Aug 17, 12:23 pm, Derek Chen-Becker <dchenbec...@gmail.com> wrote:
>
> Thanks for the small self-contained project.
>
> I get it now. Your example shows 2 things:
>
> - setSequential should definitely imply shareVariables because if
>
> examples are executed as soon as they are met, there's no way we can
>
> duplicate the specification to execute them with their own set of
>
> 'fresh' variables.
>
> This is what's causing the duplication you've seen and I'm going to
>
> fix that.
>
> - setSequential should have been left apart, with
>
> LiterateSpecification where is was created.
>
> For the future work on specs I think that it will make sense to
>
> clarify 2 styles of specifications:
>
> - "declarative" where the initial local variables are not shared so
>
> that examples are independent
>
> - "narrative" where the examples are telling a "story", building on
>
> each other resulting state like in your database example
>
> E.
>
>
> > OK, per your explanation on setSequential and shareVariables, I did some
>
> > further testing and I've isolated some things (a tiny bit). In my code, if I
>
> > don't specify any special handling, the test works fine:
>
> >
>
> > "EntityManager" should {
>
> > "Add users" in {
>
> > ...
>
> >
>
> > if I explicitly set shareVariables, it also runs fine:
>
> >
>
> > "EntityManager" should {
>
> > shareVariables()
>
> > "Add users" in {
>
> > ...
>
> >
>
> > if I do both setSequential and shareVariables (in either order), it runs
>
> > fine:
>
> >
>
> > "EntityManager" should {
>
> > setSequential()
>
> > shareVariables()
>
> > "Add users" in {
>
> >
>
> > -or-
>
> >
>
> > "EntityManager" should {
>
> > shareVariables()
>
> > setSequential()
>
> > "Add users" in {
>
> >
>
> > However, if I set only setSequential, it fails:
>
> >
>
> > "EntityManager" should {
>
> > setSequential()
>
> > "Add users" in {
>
> >
>
> > I get the same behavior under both Specs 1.6.2.2 and 1.6.5. Granted, now I
>
> > understand that I don't even need to use setSequential, but it still seems
>
> > odd that the tests run multiple times if I do use it. I've attached a
>
> > self-contained test-case.
>
> >
>
> > Derek
>
> >
>
> >
>
> >
>
> > On Mon, Aug 16, 2010 at 5:07 PM, etorreborre <etorrebo...@gmail.com> wrote:
>
> > > Hmm, that's supposed to be the same thing, with the same fixes
>
> >
>
> > > 1.6.2.2 is for scala 2.7.7
>
> > > 1.6.5 is for scala 2.8.0
>
> >
>
> > > And now that 2.8.0 is out, my plan was to go on fixing things on the
>
> > > 2.8.0 mostly and refactoring on that branch also.
>
> > > Maintaining refactorings on 2 different scala branches would be too
>
> > > tedious so I think I will mostly backport fixes on demand.
>
> >
>
> > > So if you're back, at some point, to 2.7.7 and you still have this
>
> > > issue, please send me your project so that I can find a relevant fix.
>
> >
>
> > > Thanks,
>
> >
>
> > > Eric
>
> >
>
> > > On Aug 17, 8:30 am, Derek Chen-Becker <dchenbec...@gmail.com> wrote:
>
> > > > Hmmm. On a guess I moved over to Specs 1.6.5 and Scala 2.8.0 from Specs
>
> > > > 1.6.2.2 (the latest I could find for 2.7.7) and now the issue doesn't
>
> > > occur
>
> > > > anymore. Was this something you might have fixed in the interim? Do you
>
> > > have
>
> > > > plans to release 1.6.5 for Scala 2.7.7?
>
> >
>
> > > > Thanks,
>
> >
>
> > > > Derek
>
> >
>
> > > > On Mon, Aug 16, 2010 at 3:24 PM, etorreborre <etorrebo...@gmail.com>
>
> > > wrote:
>
> > > > > Yes Derek send me a full project showing the issue (or even better a
>
> > > > > small one :-)).
>
> >
>
> > > > > On Aug 17, 3:36 am, Derek Chen-Becker <dchenbec...@gmail.com> wrote:
>
> > > > > > Comments inline:
>
> >
>
> > > > > > On Sun, Aug 15, 2010 at 7:25 AM, etorreborre <etorrebo...@gmail.com>
>
> > > > > wrote:
>
> > > > > > > Actually "setSequential" and "shareVariables" were born in 2
>
> > > different
>
> > > > > > > contexts. "setSequential" came from the need to have examples being
>
> > > > > > > executed right away in a LiterateSpecification (still experimental)
>
> > > in
>
> > > > > > > order to display some resulting state in the following text. On the
>
> > > > > > > other hand, "shareVariables" came from the need to avoid specs
>
> > > default
>
> > > > > > > mode where local variables are reinitialized as a facility when
>
> > > > > > > executing the tests.
>
> >
>
> > > > > > > So effectively "shareVariables" also means "setSequential" because
>
> > > if
>
> > > > > > > you allow side effects to happen, the order in which they happen
>
> > > must
>
> > > > > > > be well defined. Well,... unless you don't care, which must be also
>
> > > > > > > possible but I fail to see a useful test/specification situation
>
> > > were
>
> > > > > > > that would be the case.
>
> >
>
> > > > > > Thanks, this actually clears up some misunderstanding I had about the
>
> > > way
>
> > > > > > the specs initialized and ran.
>
> >
>
> > > > > > > Now about the specification in your gist, you can wonder if the
>
> > > first
>
> > > > > > > and second examples are not redundant because there's no way to
>
> > > know
>
> > > > > > > if persisting worked ok unless you do a find. This leaves us with
>
> > > > > > > essentially 2 examples where you could factor out the creation of
>
> > > the
>
> > > > > > > 2 users as a doFirst action, to setup the system and one example
>
> > > > > > > specifying the find, the other one doing the delete. I'm not saying
>
> > > at
>
> > > > > > > all that's *the* way to do it, just showing another option.
>
> >
>
> > > > > > I see your point, but in this particular case, the insert clause is
>
> > > there
>
> > > > > > because I had a regression in a previous version where the second
>
> > > insert
>
> > > > > > wasn't working properly, so in my mind it really is a test of proper
>
> > > > > > insertions.
>
> >
>
> > > > > > > That being said, in the example you're showing you shouldn't have
>
> > > to
>
> > > > > > > use "setSequential" because examples are executed in order anyway.
>
> > > And
>
> > > > > > > in any case, you should not observe any repetition and I need to
>
> > > > > > > investigate that. Which runner are you using? Maven, sbt?
>
> >
>
> > > > > > It happens when I run either. I can provide a full SBT/Maven project
>
> > > for
>
> > > > > you
>
> > > > > > to run if that would help you.
>
> >
>
> > > > > > Derek
>
> >
>
> > > > > > > Eric.
>
> >
>
> > > > > > > On Aug 14, 2:40 pm, Derek Chen-Becker <dchenbec...@gmail.com>
>
> > > wrote:
>
> > > > > > > > Yeah, I suspected that. Turning on shareVariables() makes it work
>
> > > as
>
> > > > > I
>
> > > > > > > > expected. While I understand the logic behind isolating the
>
> > > tests, I
>
> > > > > > > would
>
> > > > > > > > argue that explicitly configuring a set of clauses to be run in
>
> > > > > sequence
>
> > > > > > > > implies a dependence between them.
>
> >
>
> > > > > > > > Derek
>
> >
>
> > > > > > > > On Fri, Aug 13, 2010 at 6:11 PM, etorreborre <
>
> > > etorrebo...@gmail.com>
>
> > > > > > > wrote:
>
> > > > > > > > > Hi Derek and Kris,
>
> >
>
> > > > > > > > > I'm going to investigate this during the week-end but my laptop
>
> > > is
>
> > > > > > > > > dead for now, I need to setup a replacement :-(
>
> >
>
> > > > > > > > > Derek, the issue you're observing may be a result of running
>
> > > each
>
> > > > > > > > > example in isolation by cloning the specification.
>
> > > > > > > > > Maybe what you can try, until I have a look at it, is to add
>
> > > > > > > > > shareVariables() to keep the whole execution in the
>
> > > > > > > > > same specification effectively sharing the local variables.
>
> >
>
> > > > > > > > > Eric.
>
> >
>
> > > > > > > > > On Aug 14, 4:50 am, Derek Chen-Becker <dchenbec...@gmail.com>
>
> > > > > wrote:
>
> > > > > > > > > > If I understand what you're saying then I think I'm already
>
> > > doing
>
> > > > > > > that.
>
> > > > > > > > > > Here's the code in question:
>
> >
>
> > > > > > > > > >http://gist.github.com/523347
>
> >
>
> > > > > > > > > > Does that look right?
>
> >
>
> > > > > > > > > > On Fri, Aug 13, 2010 at 12:33 PM, Kris Nuttycombe <
>
> > > > ...
>
> read more »
Derek Chen-Becker
Aug 23, 2010, 1:02:18 PM8/23/10
to specs...@googlegroups.com
Seems to be working fine for me. Thanks!
Derek
Derek
Reply all
Reply to author
Forward
0 new messages