moertel / squcumber-postgres

Cucumber-based framework for defining and executing SQL unit, integration and acceptance tests for PostgreSQL databases

Hi, I'm Stefanie!   ^{👾 》I automate ALL the things. GitOps & DataOps advocate. I test my code. Occasionally, I draw.}

---

       

Senior Data & Platform Engineer 》working in Data, Reliability Analytics & Automation
Digital Artist & Creator 》specialised in neo-noir pixel art animations and 8bit-ish art

---

|     Website & Gallery : https://moer.tel    |    Open Source Work : _{▼ ▼ ▼}

squcumber-postgres's Issues

Parentheses "()" are being removed from table values

Given the existing table "some_table":
  | some_column |
  | foo (bar)   |
When the resulting table "some_table" is queried
Then the result exactly matches:
  | some_column |
  | foo (bar)   |

This fails with error:

Does not match exactly, got:
| some_column |
| foo         |
(RuntimeError)
./features/test.feature:1:in `Then the result exactly matches:'

Values with parentheses are just stripped from the table data.

Allow a table definition to be empty

Sometimes a table used in a query will be left empty in the scope of the test to check a particular behaviour of the SQL. Omitting the table from the test setup means that the fact of it being empty can be overlooked easily.

It would be beneficial to have a way to explicitly state a table as being empty.

Given the existing table "tracking.kpi" is empty

Single quotes need to be escaped

This test will throw a syntax error because of the single quotes:

Feature: Imma feature
  Background:
    Given the SQL files in the path "/sql":
      | file                      |
      | testing_things.sql        |
    And their table dependencies:
      | table                     |
      | schema.table            |


    Scenario: Adopted customer
      Given the existing table schema.table with date placeholders:
        | name |
	| This has 'quotes' | 
      When the given SQL files are executed and the result is returned
      Then the result exactly matches:
        | name |
        | This has 'quotes' |

ERROR: syntax error at or near "quotes" squcumber-app | LINE 1: ...sert into schema.table (name) values ('This has 'quotes'')

where name is varchar(255)

in order to make the test pass, we need to escape the quotes

Feature: Imma feature
  Background:
    Given the SQL files in the path "/sql":
      | file                      |
      | testing_things.sql        |
    And their table dependencies:
      | table                     |
      | schema.table            |


    Scenario: Adopted customer
      Given the existing table schema.table with date placeholders:
        | name |
	| This has ''quotes'' | 
      When the given SQL files are executed and the result is returned
      Then the result exactly matches:
        | name |
        | This has 'quotes' |

Allow date placeholders in result sets

Allow for the following Then clause:

Then the result exactly matches with date placeholders
| foo | date_bar  |
| 1     | 1 day ago |

Non-existent column names silently ignored in "Then" steps

Only columns that are under test need to be specified in a result step. Should the actual result that is returned from a table or query have columns that are not included in the expected result, these will be silently ignored.

However, if a column in the specified expectetd result has a typo, then this will inadvertently be silently ignored as well, because we only take the keys from the actual result:

sQucumber-postgres/lib/squcumber-postgres/step_definitions/common_steps.rb

Lines 130 to 132 in 5c94ee6

	row.all? do |key, value|
	values_match(value, hash[key]) # actual,expected
	end

An error should be raised if a non-existent column name is specified in the expected result.

Add support for queries that don't create tables

Something along the lines of:

When(/^the given SQL files are executed and the result is kept$/) do
  silence_streams(STDERR) do
    @sql_files_to_execute.each do |file|
      sql = File.read(file)
      @result = TESTING_DATABASE.query(sql).map { |e| e }
    end
  end
end

Undefined method when using `Then the result exactly matches`

Using the following feature file:

Feature: This just tests having a UI for SQL testing

  Background:
    Given the SQL files in the path "/opt/sql":
      | file            |
      | temp.sql        |
    And their table dependencies:
      | table           |
      | some_table |

    
   Scenario: Test
    Given the existing table "some_table":
      | login_name |
      | test       |
    When the given SQL files are executed and the result is returned
    Then the result exactly matches:
      | login_name |
      | test       |

and the SQL

select * from some_table;

I get the following error:

Feature: This just tests having a UI for SQL testing

Background: # /opt/features/temp.feature:3
Given the SQL files in the path "/opt/sql": # squcumber-postgres-0.0.7/lib/squcumber-postgres/step_definitions/common_steps.rb:17
| file |
| temp.sql |
And their table dependencies: # squcumber-postgres-0.0.7/lib/squcumber-postgres/step_definitions/common_steps.rb:35
| table |
| some_table |

Scenario: Test # /opt/features/temp.feature:12
Given the existing table "some_table": # squcumber-postgres-0.0.7/lib/squcumber-postgres/step_definitions/common_steps.rb:67
| login_name |
| test |
When the given SQL files are executed and the result is returned # step_definitions/common_steps.rb:5
Then the result exactly matches: # squcumber-postgres-0.0.7/lib/squcumber-postgres/step_definitions/common_steps.rb:151
| login_name |
| test |
undefined method `values_match' for # (NoMethodError)
./features/temp.feature:17:in `Then the result exactly matches:'

This happens for both 0.0.6 and 0.0.7. The above scenario does use a custom step. However, a similar error occurs when using When the given SQL files are executed, but only on v0.0.7

Background: # /opt/features/temp.feature:3
Given the SQL files in the path "/opt/sql": # squcumber-postgres-0.0.7/lib/squcumber-postgres/step_definitions/common_steps.rb:17
| file |
| temp.sql |
And their table dependencies: # squcumber-postgres-0.0.7/lib/squcumber-postgres/step_definitions/common_steps.rb:35
| table |
| some_table |

Scenario: Test # /opt/features/temp.feature:12
Given the existing table "some_table": # squcumber-postgres-0.0.7/lib/squcumber-postgres/step_definitions/common_steps.rb:67
| login_name |
| test |
When the given SQL files are executed # squcumber-postgres-0.0.7/lib/squcumber-postgres/step_definitions/common_steps.rb:83
Then the result exactly matches: # squcumber-postgres-0.0.7/lib/squcumber-postgres/step_definitions/common_steps.rb:151
| login_name |
| test |
undefined method `length' for # (NoMethodError)
./features/temp.feature:17:in `Then the result exactly matches:'

Failing Scenarios:
cucumber /opt/features/temp.feature:12 # Scenario: Test

---

Edit by @grunwald: Anonymised table names to not leak business information.

Better error message when table is not defined as dependency

When a query uses a table or schema that has not been defined as a dependency, the generic Postgres error Table foo does not exist pops up and is little help in figuring out what's wrong. A better error message would be good.

Add support for custom step definitions

I want an easy way to add additional step definitions without overriding the entire startup command.

Using the step`Given the existing table` results error if not defined in Background

Using the step Given the existing table "some_schema.some_table" will break if the table hasn't previously been defined in the Background step Given their table dependencies. This is not intuitive because the given step does imply that a fixture is added with it.

An obvious solution would be to add a table implicitly when that step is called.