Group items tagged

models directory is meant to hold tests for your models

controllers directory is meant to hold tests for your controllers

integration directory is meant to hold tests that involve any number of controllers interacting

Fixtures are a way of organizing test data; they reside in the fixtures folder

The test_helper.rb file holds the default configuration for your tests

Fixtures allow you to populate your testing database with predefined data before your tests run

Fixtures are database independent written in YAML.

one file per model.

Each fixture is given a name followed by an indented list of colon-separated key/value pairs.

Keys which resemble YAML keywords such as 'yes' and 'no' are quoted so that the YAML Parser correctly interprets them.

define a reference node between two different fixtures.

ERB allows you to embed Ruby code within templates

The YAML fixture format is pre-processed with ERB when Rails loads fixtures.

Rails by default automatically loads all fixtures from the test/fixtures folder for your models and controllers test.

Fixtures are instances of Active Record.

access the object directly

test_helper.rb specifies the default configuration to run our tests. This is included with all the tests, so any methods added to this file are available to all your tests.

test with method names prefixed with test_.

An assertion is a line of code that evaluates an object (or expression) for expected results.

bin/rake db:test:prepare

Every test contains one or more assertions. Only when all the assertions are successful will the test pass.

rake test command

run a particular test method from the test case by running the test and providing the test method name.

The . (dot) above indicates a passing test. When a test fails you see an F; when a test throws an error you see an E in its place.

we first wrote a test which fails for a desired functionality, then we wrote some code which adds the functionality and finally we ensured that our test passes. This approach to software development is referred to as Test-Driven Development (TDD).

SysBench is not a tool which you can use to tune configurations of your MySQL servers (unless you prepared LUA scripts with custom workload or your workload happen to be very similar to the benchmark workloads that SysBench comes with)

it is great for is to compare performance of different hardware.

Every new server acquired should go through a warm-up period during which you will stress it to pinpoint potential hardware defects

by executing OLTP workload which overloads the server, or you can also use dedicated benchmarks for CPU, disk and memory.

bulk_insert.lua. This test can be used to benchmark the ability of MySQL to perform multi-row inserts.

All oltp_* scripts share a common table structure. First two of them (oltp_delete.lua and oltp_insert.lua) execute single DELETE and INSERT statements.

oltp_point_select, oltp_update_index and oltp_update_non_index. These will execute a subset of queries - primary key-based selects, index-based updates and non-index-based updates.

you can run different workload patterns using the same benchmark.

Warmup helps to identify “regular” throughput by executing benchmark for a predefined time, allowing to warm up the cache, buffer pools etc.

By default SysBench will attempt to execute queries as fast as possible. To simulate slower traffic this option may be used. You can define here how many transactions should be executed per second.

SysBench gives you ability to generate different types of data distribution.

decide if SysBench should use prepared statements (as long as they are available in the given datastore - for MySQL it means PS will be enabled by default) or not.

sysbench ./sysbench/src/lua/oltp_read_write.lua  help

By default, SysBench will attempt to execute queries in explicit transaction. This way the dataset will stay consistent and not affected: SysBench will, for example, execute INSERT and DELETE on the same row, making sure the data set will not grow (impacting your ability to reproduce results).

specify error codes from MySQL which SysBench should ignore (and not kill the connection).

the two most popular benchmarks - OLTP read only and OLTP read/write.

1 million rows will result in ~240 MB of data. Ten tables, 1000 000 rows each equals to 2.4GB

by default, SysBench looks for ‘sbtest’ schema which has to exist before you prepare the data set. You may have to create it manually.

pass ‘--histogram’ argument to SysBench

~48GB of data (20 tables, 10 000 000 rows each).

if you don’t understand why the performance was like it was, you may draw incorrect conclusions out of the benchmarks.