testing with managed-fixture

Одной из распространенных проблем в модульном тестировании является работа с базой данных (или любым внешними сущностями, которые мутабельны не потому что у программиста руки кривые, а потому что так мир устроен)


То есть в таком случае получается, что либо у нас все тесты расчитаны на определенное состояние БД и при этом не меняют ее состояние (к примеру, исполняются в rollback транзакции), либо какая-то последовательность выполнения тестов и изменения состояния БД описывается руками.

Что-то меня эта ситуация стала напрягать, до такой степени, что я реализовал простой DSL и расширение к scalatest, позволяющие писать нечто вроде:

import ua.gradsoft.testing._
import org.scalatest.managedfixture._

class MyFlatSpec extends managedfixture.[DBFixtureStateTypes.type]
{
 val fuxtureStateTypes = DBFixtureStateTypes
 val fuxtureAccess = DBFixtureAccess
 import DBFixtureStateTypes.States._

 behavior of "My datababase"

 start state(INITIAL) finish state(WITH_ONE)
 it should "be able to add user " in { db =>
    .....
 }

 start state(DATASET1) change(nothing) parallel
 it should "retrieve user with name Jon in our test dataset" in { db =>
    inTransaction {
       val x = db.selectUser("Jon").headOption;
       assert(x!=None)
       assert(x.name == "Jon")
    }
 }

(Здесь перед каждым тестом описано на mini-dsl -- какое начальное состояние требуется для теста и как он его меняет (и если не меняет -- может ли исполняться параллельно с другими))

При выполнении, все тесты в наборе разбиваются на группы, внутри одной группы тесты требуют одинаковое состояние БД и выполняются параллельно, а сами группы выстраиваются в последовательность исполнения, такую что бы число загрузок состояния БД было минимальным)

Вроде работает. Обнаружил попутно, что scalatest внутри довольно архаичный и начал смотреть в сторону spec2 (но там прийдется и фикстуры дописывать)

URL: http://rssh.github.com/fixture-state-management/ может кому пригодится