On 14/06/12 15:16, Michael MacFadden wrote:
> Have we looked at the previous ant build to see what it did?ยด

As I've stated before, it would fail with no explanation why. Of course,
looking at the test reports one would notice there was no Mongo DB
running on localhost.

>
> On Jun 14, 2012, at 7:14 AM, Paulo Pires wrote:
>
>>
>> On 14/06/12 15:04, Ali Lown wrote:
>>>>>> Is anyone against having an instance of Mongo DB instantiated and
>>>>>> destroyed when tests are run? I'm already assuming the developer doesn't
>>>>>> need to have Mongo DB already installed, as well.
>>>>> How much of an overhead is that going to add to the running of the
>>>>> tests? Inutition suggests that instantiating a DB is going to be a
>>>>> pretty heavy job...
>>>> It will only take 30 seconds or a little less/more (depending on your
>>>> internet connection) to download the Mongo distribution for your
>>>> OS/arch. After that, database population, tests and shutdown take around
>>>> 15 seconds (Core 2 Duo 2.4 GHz, 4GB DDR2, SSD disk).
>>> That sounds reasonable for testing. (Though I don't think fetching
>>> outside of distro-specific package managers is a good idea. An error
>>> saying please install MongoDB from your distro's package repository
>>> before running these tests would be ok.)
>> It's not going to install Mongo. It's just going to extract it to a
>> local directory and use it. When the test JVM finishes, the instance
>> will be shutdown.
>>
>> If you ever delete that local directory, then it will download again and
>> so on.
>>
>>>> Btw, just to clarify, I have only one Mongo DB instance for all tests
>>>> and not an instance per test.
>>> Can you be sure of full isolation if you setup one instance and then
>>> run each test? You would need to revert all changes at the end of each
>>> test before you could run the next...
>> This *should* be enforced by each test and not the tools we're using,
>> being it Mongo or any other.
>>
>> And this has been done before, since every test already implements the
>> following:
>>
>>  @Override
>>  protected void tearDown() throws Exception {
>>    super.tearDown();
>>    database.dropDatabase();
>>  }
>>
>> -- 
>> Paulo Pires
>>

-- 
Paulo Pires

Reply via email to