When using before(:all) to create records in the database, you should use
after(:all) to clean that up.
Sometimes when you need to setup a lot of data, this can speed your tests a
lot.
Otherwise avoid it.
On Friday, November 25, 2011 3:04:08 PM UTC+1, Zhi-Qiang Lei wrote:
>
> Hi,
>
> When I te
On Nov 25, 2011, at 8:04 AM, Zhi-Qiang Lei wrote:
> Hi,
>
> When I test my Rails controller, I find that records created in before(:all)
> remain in database while records created in before(:each) and let are wiped
> out after testing. This made me run "rake test:prepare" for every new test.
>
Yes,
Only before :each is run in transaction. You should avoid creating
records in the before :all hook
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Hi,
When I test my Rails controller, I find that records created in before(:all)
remain in database while records created in before(:each) and let are wiped out
after testing. This made me run "rake test:prepare" for every new test. Is that
normal?
Best regards,
Zhi-Qiang Lei
zhiqiang@gmai
Thanks for your answers. I'll use a fixture replacement to set up the
environment.
I know that this (using before(:all) to setup a state) is not a best practice.
In this case however, I would consider my approach to be acceptable as the pdf
takes a long time to generate. All tests run on the sa
On Jul 13, 2010, at 7:25 AM, Ivo Dancet wrote:
> Hi
>
> I'm upgrading an application to rspec2/rails3. A certain suite of tests, that
> generates a pdf document, uses a before(:all) filter to set the environment
> using mocks and stubs. Then the pdf gets generated and after that all the
> test
I know that generally it is not considered best practice to user
before(:all) and after(:all) as state is shared between all examples, which
is a unit-testing anti-pattern. The rspec book recommends setting up
fixtures and environment for each example. Perhaps to drive this point home,
support for
Hi
I'm upgrading an application to rspec2/rails3. A certain suite of tests, that
generates a pdf document, uses a before(:all) filter to set the environment
using mocks and stubs. Then the pdf gets generated and after that all the tests
run on that same pdf document. In rspec2 it seems like I c
On Thu, Jul 9, 2009 at 9:37 AM, Daniel Tenner wrote:
>> 2) Is it your goal to call "some_expensive_operation" once and only once?
>
> Yes, exactly. In the case of the project archival spec, creating a project,
> archiving it, and then unzipping it to a temporary location to look at what
> was archi
>
> 2) Is it your goal to call "some_expensive_operation" once and only once?
Yes, exactly. In the case of the project archival spec, creating a project,
archiving it, and then unzipping it to a temporary location to look at what
was archived is a process that takes about 3 seconds on my machine.
Rereading your original email, I'm thinking I may not have entirely
understood your situation.
1) Looks like you've already defined the
"some_expensive_operation" (but that's minor)
2) Is it your goal to call "some_expensive_operation" once and only
once?
On Jul 9, 2009, at 10:18 AM,
Hey Dan,
1 approach you could do is define a method within the outer describe
that is called within the inner describe and within each test not
contained by an inner describe.
describe "Some functionality" do
it "should do something" do
@variable = some_expensive_operation
@variab
On Thu, Jul 9, 2009 at 5:40 AM, Daniel Tenner wrote:
> Hi all,
> Like everyone (?), I use nested contexts to keep my specs well organised and
> tidy.
> However, I have a problem. I have various sets of specs that needs to
> perform very time-expensive operations to set up the fixtures that will be
To answer myself, I've put together the following work-around:
http://www.swombat.com/getting-rspec-beforeall-and-nested-contexts-w
Still, would love to know if there was a better, less hackish way to do it.
Daniel
On Thu, Jul 9, 2009 at 11:40 AM, Daniel Tenner wrote:
> Hi all,
> Like everyone
Hi all,
Like everyone (?), I use nested contexts to keep my specs well organised and
tidy.
However, I have a problem. I have various sets of specs that needs to
perform very time-expensive operations to set up the fixtures that will be
examined in the tests. Two specific examples: testing access c
On Sun, Jun 7, 2009 at 9:40 PM, lawrence.pit wrote:
> Hi,
>
> I took a stab at this and created what I call Machinery. So far it
> works great for me.
>
> For those that are looking for a way to create objects in the database
> in a before(:all) instead of a before(:each) to speed up tests, have a
Hi,
I took a stab at this and created what I call Machinery. So far it
works great for me.
For those that are looking for a way to create objects in the database
in a before(:all) instead of a before(:each) to speed up tests, have a
look at:
http://github.com/lawrencepit/machinery
Cheers,
Lawr
On Wed, May 20, 2009 at 10:27 PM, lawrence.pit wrote:
> Hi All,
>
> When I execute database actions within a before(:each) they are rolled
> back after each example test has run. I expected that if I execute db
> actions within a before(:all) they would all be rolled back after all
> examples fini
Hi All,
When I execute database actions within a before(:each) they are rolled
back after each example test has run. I expected that if I execute db
actions within a before(:all) they would all be rolled back after all
examples finished running. This appears not to be the case, in my
case. Is ther
19 matches
Mail list logo
