Re: TDD Database migration code

A tool as Liquibase (http://www.liquibase.org/) would not help?

>>*The short version is:
 >>1. A command which generates a .sql file with a timestamp in the file
name.
In liquibase you create de .sql files.
>>  2. A command which checks all the files in a folder, and then does some
comparisons to another db, and picks one or more .sql files to run on the
db in question.
I think that is exactly what liquibase does.



On Wed, Apr 20, 2016 at 9:01 AM, Avi Kessner [email protected]
[testdrivendevelopment] <[email protected]> wrote:

>
>
> Ironically, after attempting to install pgTap and get it talking with
> python instead of perl, I ended up removing all the tests and DB specific
> code.
>
> Mainly because of what you were advising just now. The custom use cases
> were making my tests too brittle, so I found a better way to abstract it
> out.
>
> It will be good later on though if we have more complicated db functions,
> though hopefully I'll be able to persuade the team to avoid that.
>
> brought to you by the letters A, V, and I
> and the number 47
>
> On Wed, Apr 20, 2016 at 2:17 PM, Adam Sroka [email protected]
> [testdrivendevelopment] <[email protected]> wrote:
>
>>
>>
>> You are welcome!
>>
>> General advice: be cautious about building functionality into the
>> database. The database should be optimized for storage and retrieval.
>> Decisions about how to ask the right questions of the database should
>> probably be in a layer closer to the customer, and in the language
>> appropriate to that place.
>>
>> On Wed, Apr 20, 2016 at 1:06 AM, Avi Kessner [email protected]
>> [testdrivendevelopment] <[email protected]> wrote:
>>
>>>
>>>
>>> PgTap looks perfect. Thanks!
>>> On Apr 20, 2016 10:59 AM, "Avi Kessner" <[email protected]> wrote:
>>>
>>>> Ideally I'm looking for something that creates databases, runs sql, is
>>>> able to check the state of the database, and then destroys the database.
>>>>
>>>> I don't really care at what level that happens at. (Though easier is
>>>> obviously better)  .. (investigating pgtap now, thanks)
>>>>
>>>> brought to you by the letters A, V, and I
>>>> and the number 47
>>>>
>>>> On Wed, Apr 20, 2016 at 10:21 AM, Adam Sroka [email protected]
>>>> [testdrivendevelopment] <[email protected]> wrote:
>>>>
>>>>>
>>>>>
>>>>> Are you talking about test driving database access code from a general
>>>>> purpose language? Or are you talking about test driving stuff inside the
>>>>> database engine? There is http://pgtap.org/ but I would look for a
>>>>> way to do it at a higher level, unless... a gun was pointed at my head.
>>>>>
>>>>> On Tuesday, April 19, 2016, [email protected]
>>>>> [testdrivendevelopment] <[email protected]> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> My google searches are giving me bad results... :(
>>>>>>
>>>>>> Does anyone know of any good articles, or have any good hints, on how
>>>>>> to do TDD for writing PostgresSQL, or database code?
>>>>>>
>>>>>> I need to write a custom system which allows us to do DB migrations
>>>>>> and updates etc, a bit similar to what Ruby on Rails with has their DB
>>>>>> rake:migration command.*
>>>>>>
>>>>>> Google is mostly giving me information on how to abstract out DB
>>>>>> objects, but I need to verify that my new custom migration system is
>>>>>> actually working.
>>>>>>
>>>>>> The tests I would want to write are simples
>>>>>>    1. Confirm that a migration file worked (say by adding a column)
>>>>>>    2. Confirm that only the latest migration was run, and not a
>>>>>> previous one (say by checking a value in the table wasn't changed)
>>>>>>
>>>>>> I appreciate the help you can provide.
>>>>>>
>>>>>> *The short version is:
>>>>>>  1. A command which generates a .sql file with a timestamp in the
>>>>>> file name.
>>>>>>   2. A command which checks all the files in a folder, and then does
>>>>>> some comparisons to another db, and picks one or more .sql files to run on
>>>>>> the db in question.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>
> 
>



-- 
Abraços,
Josué
http://twitter.com/josuesantos