Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create sql-writting-tests.md #105

Merged
merged 15 commits into from
Aug 4, 2020
81 changes: 81 additions & 0 deletions content/languages/sql/sql-writting-tests.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,81 @@
---
description: ""
kind: tutorial
languages: [sql]
topic: tests
tags:
- testing
Blind4Basics marked this conversation as resolved.
Show resolved Hide resolved
---

# Writting tests for SQL
Blind4Basics marked this conversation as resolved.
Show resolved Hide resolved

## Generalities

If you do use an existing SQL kata, be sure to avoid exposing the solution in the preloaded code file. It's easy for a code warrior to read the file in the sample tests and view the solution. Also, drop and recreate the database per `it` block so that there's no surprising state shared across cases.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is weird as a first sentence on this page.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll check that one tomorrow (too much tired for that now. It's actually the original text, I just updated the post of the issue to make it compatible with the docs.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried something... Can you check again, plz?


Here's an opinionated suggestion of how to test SQL which is similar to the "insert example" button in the new kata editor. In both cases, sample tests are explicitly visible to the code warrior rather than buried in the interface with `compare_with`, which many challenges use and abuse. Even if the challenger is not familiar with Ruby, it's less magical and easier to debug when exposed. They're always free to ignore the test cases. I prefer a close to 1:1 ratio between `it` block and `expect` calls so the challenger can localize their problem easily.

Disadvantages of this approach are that the challenger might be surprised or confused by the Ruby code, so offering an explanatory note at the end of the instructions can go a long way to mitigating this. Another possible downside is that the test file can become verbose, so you can strategically move some of the content to helper functions in the preloaded file.

Other than Codewars' `run_sql` function, the optional diff table code and interactions with the [DB object](https://github.com/jeremyevans/sequel#label-A+Short+Example), the code uses normal RSpec comparisons on an array of hashes.

Random tests are important to include for the submission to prevent cheating and can use [Faker](https://github.com/faker-ruby/faker) and Ruby's [Random](https://ruby-doc.org/core-2.4.0/Random.html) class.
Blind4Basics marked this conversation as resolved.
Show resolved Hide resolved

## Example instructions:
Blind4Basics marked this conversation as resolved.
Show resolved Hide resolved

Write a query to retrieve all rows from the `widgets` table where the varchar widget `name` column starts with the substring `"foo"`. _...Include examples, schema images, etc..._

## Complete solution:
Blind4Basics marked this conversation as resolved.
Show resolved Hide resolved

```sql
SELECT * FROM widgets WHERE widgets.name LIKE 'foo%';
```

## Initial solution:
Blind4Basics marked this conversation as resolved.
Show resolved Hide resolved

```sql
-- Write your query here
```

## Preloaded code:
Blind4Basics marked this conversation as resolved.
Show resolved Hide resolved

```ruby
def show_diff_table(actual, expected)
daff_data = DaffWrapper.new(
actual,
expected,
index: true
).serializable
Display.daff_table(
daff_data,
label: "Diff",
tab: true,
allow_preview: true
)
end
```

## Test cases and example test cases:
Blind4Basics marked this conversation as resolved.
Show resolved Hide resolved

```ruby
describe "Query tests" do
after(:each) {DB.drop_table?(:widgets)}
before(:each) do
DB.create_table(:widgets) do
primary_key(:id)
varchar(:name)
end
end

it "should work on an example test" do
DB[:widgets].insert(name: "foo")
DB[:widgets].insert(name: "quux")
DB[:widgets].insert(name: "foobar")
expected = [{:id => 1, :name => "foo"},
{:id => 3, :name => "foobar"}]
actual = run_sql.to_a()
show_diff_table(actual, expected)
expect(actual).to eq(expected)
end
end
```