Hello, I just ran into a bug in my application in which the behavior differed depending on whether there was a single element in a particular table or multiple elements in the table. Right after I fixed the bug, I thought to myself, "I wonder how I could have structured a functional test to detect this?" For my simple application, I am perfectly happy to use fixtures and ActionController::TestCase. I have a fixture with multiple records in it. If I wanted to test my application with a single record, and then test it again with multiple records, how could I do that? Any thoughts? --wpd
Hi Patrick, On Tue, 2009-08-25 at 13:38 -0400, Patrick Doyle wrote:> Hello, > I just ran into a bug in my application in which the behavior differed > depending on whether there was a single element in a particular table > or multiple elements in the table. Right after I fixed the bug, I > thought to myself, "I wonder how I could have structured a functional > test to detect this?" > > For my simple application, I am perfectly happy to use fixtures and > ActionController::TestCase. I have a fixture with multiple records in > it. If I wanted to test my application with a single record, and then > test it again with multiple records, how could I do that?Fixtures are not the only way to load your test database. You can do whatever you want along the lines of db prep in your individual test methods. HTH, Bill
You are describing different test cases. In most of my applications, I test how the application works when there are 0, 1 or >1 records for a given scenario. Those are three separate tests in my application. Fixtures/factories are just used to setup the conditions for the test. Eric On Aug 25, 6:26 pm, bill walton <bwalton...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Hi Patrick, > > On Tue, 2009-08-25 at 13:38 -0400, Patrick Doyle wrote: > > Hello, > > I just ran into a bug in my application in which the behavior differed > > depending on whether there was a single element in a particular table > > or multiple elements in the table. Right after I fixed the bug, I > > thought to myself, "I wonder how I could have structured a functional > > test to detect this?" > > > For my simple application, I am perfectly happy to use fixtures and > > ActionController::TestCase. I have a fixture with multiple records in > > it. If I wanted to test my application with a single record, and then > > test it again with multiple records, how could I do that? > > Fixtures are not the only way to load your test database. You can do > whatever you want along the lines of db prep in your individual test > methods. > > HTH, > Bill
2009/8/26 E. Litwin <elitwin-ur4TIblo6goN+BqQ9rBEUg@public.gmane.org>:> > You are describing different test cases. > > In most of my applications, I test how the application works when > there are 0, 1 or >1 records for a given scenario. > Those are three separate tests in my application. Fixtures/factories > are just used to setup the conditions for the test.I think the OP understands that, the question is how to use fixtures to load different numbers of records to the table for different tests. Colin> On Aug 25, 6:26 pm, bill walton <bwalton...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> Hi Patrick, >> >> On Tue, 2009-08-25 at 13:38 -0400, Patrick Doyle wrote: >> > Hello, >> > I just ran into a bug in my application in which the behavior differed >> > depending on whether there was a single element in a particular table >> > or multiple elements in the table. Right after I fixed the bug, I >> > thought to myself, "I wonder how I could have structured a functional >> > test to detect this?" >> >> > For my simple application, I am perfectly happy to use fixtures and >> > ActionController::TestCase. I have a fixture with multiple records in >> > it. If I wanted to test my application with a single record, and then >> > test it again with multiple records, how could I do that? >> >> Fixtures are not the only way to load your test database. You can do >> whatever you want along the lines of db prep in your individual test >> methods. >> >> HTH, >> Bill > > >