Amber: `crystal spec` in a generated app runs against the development database

Created on 8 Jan 2018  路  10Comments  路  Source: amberframework/amber

Amber new generates a spec_helper which doesn't set the AMBER_ENV var explicitly to test, which means that any time specs are actually written and used, the Model.clear statements dropped all over the place nuke the development database.

Additional Information

I'm able to get a halfway decent working crystal spec command with this spec_helper:

require "spec"
ENV["AMBER_ENV"] = "test"

require "amber"
# require config before models, so they know how to connect to the database
require "../config/*"

# load up some database stuff and blindly run migrations, hoping for the best
require "micrate"
require "pg"
require "sqlite"
require "mysql"
Micrate::DB.connection_url = Amber.settings.database_url
Micrate::Cli.run_up

require "../src/ext/extensions"
require "../src/controllers/application_controller"
require "../src/controllers/**"
require "../src/mailers/**"
require "../src/models/**"
require "../src/policies/**"
require "../src/jobs/**"

Spec.before_each do
  Model.clear
  Model2.clear
  # etc
end

馃

bug

Most helpful comment

I like Spec2 - it has a lot of the nice things from RSpec.

I don't think it should be the default for amber though. It adds an additional DSL that someone has to learn to write tests for amber.

I think the solution for this issue is to make sure that a generated app sets the correct environment when tests are run, and has an easy way to setup (prepare) the test database.

All 10 comments

With the new version of amber your spec file should look more like this

require "spec"
require "garnet_spec"
require "../config/*"

module Spec
  DRIVER = :chrome
  PATH   = "/usr/local/bin/chromedriver"

  # Not all server implementations will support every WebDriver feature.
  # Therefore, the client and server should use JSON objects with the properties
  # listed below when describing which features a session supports.
  capabilities = {
    browserName:              "chrome",
    version:                  "",
    platform:                 "ANY",
    javascriptEnabled:        true,
    takesScreenshot:          true,
    handlesAlerts:            true,
    databaseEnabled:          true,
    locationContextEnabled:   true,
    applicationCacheEnabled:  true,
    browserConnectionEnabled: true,
    cssSelectorsEnabled:      true,
    webStorageEnabled:        true,
    rotatable:                true,
    acceptSslCerts:           true,
    nativeEvents:             true,
    args:                     "--headless",
  }
end

@robacarp - Just in case you aren't aware of the behavior of crystals Spec.before_each here:

Spec.before_each do
  Model.clear
  Model2.clear
  # etc
end

That block of code will run before every single spec. It doesn't matter what file or what scope.

@marksiemers Thank you! Yes, I am aware and thats actually why I moved them into the spec_helper.cr file. As generated, each model was getting .clear called several times per spec because it was registered multiple times in the spec suite: once for the controller test and once for the model test.

This might mean that providing amber spec might be a good idea. Either that or someone might be able to run an individual spec file that doesn't set AMBER_ENV to test.

I suppose we can try to structure it so that no matter what it gets set, but once a user starts writing tests, there is no guarantee.

I think that spec_helper is a necessary enough part of a test run, so anything that needs to be run before each test can live in there, or be included there.

or someone might be able to run an individual spec file that doesn't set AMBER_ENV to test.

I don't think it's worth catering to every possible trap people could get themselves into. If Amber provides a consistent and functional user interface for the programmer, that's sufficient.

I wanted for Amber to stay simple by using crystal specs but it seems that this odd behavior of Crystal Spec is annoying people a lot. Maybe we should consider adding https://github.com/waterlink/spec2.cr as the default spec library for running specs for an Amber project. WDYGT?

I like Spec2 - it has a lot of the nice things from RSpec.

I don't think it should be the default for amber though. It adds an additional DSL that someone has to learn to write tests for amber.

I think the solution for this issue is to make sure that a generated app sets the correct environment when tests are run, and has an easy way to setup (prepare) the test database.

Addresses with #500

Thank you @eliasjpr ! 馃尞

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ZeroPointEnergy picture ZeroPointEnergy  路  4Comments

elorest picture elorest  路  6Comments

yorci picture yorci  路  6Comments

faustinoaq picture faustinoaq  路  6Comments

eliasjpr picture eliasjpr  路  6Comments