Czechs And Slovaks On Rails

Test-first praktikuju (zatím?) jen výjimečně, ale na psaní testů jsem si už hodně zvykl. Došlo to tak daleko, že se mi jednou zdál sen, ve kterém jsem si něco koupil v krámě a ačkoliv to šlo celkem hladce, chtěl jsem poté napsat test, protože člověk nikdy neví a co když v tom postupu budu dělat změny, že. Ehm. Lakavá představa, že?

Tak tento odstavec už čtou jen opravdoví zájemci, takže můžu přejít k věci. Skoro před rokem se tu objevil článek o testovacích nástrojích. Není ale specificky pro RoR a navíc mám další zajímavosti, takže bych rád zmínil pár tipů na zjednodušení práce při psaní testů.

Základem je již několikrát zmiňovaný rcov, který vám najde řádky kódu, které nebyly testy vůbec spuštěny. Jeho rozchození se s instalací Heckle srovnávat nedá, stačí:

sudo gem install rcov

Generování statistiky pokrytí pak spustíte takovýmto příkazem zadaném v kořenovém adresáři aplikace:

rcov test/**/*rb

To vám vytvoří adresář coverage obsahují HTML soubory zobrazující pokrytí jednotlivých zdrojových souborů. Dobrým začátkem je (jak překvapivé) coverage/index.html obsahujicí přehled celého projektu.

Jak vypadá výstup pro jeden soubor se můžete podívat zde Je dobré si uvědomit, co vlastně znamená, že se některý z řádků zobrazí zeleně. Znamená to, že byl testem spuštěn, což je sice příjemné, ale nezaručuje to, že test opravdu správně testuje funkcionalitu programu. Mějme takovouto metodu:

def deposit(amount)
    if amount < 0
      raise 'eh?'
    else
      @balance += amount / 2
      transfer_money_to_my_account(amount / 2)
    end
  end

a takovéto testy:

  def test_deposit_negative_amount_raises_error
    assert_raise(RuntimeError) {@account.deposit(-1)}
  end

  def test_deposit_amount_is_successful
    assert_nothing_raised { @account.deposit(2) }
    assert @account.balance > 0
  end

Pokrytí kódu testy bude v tomto případě 100 %, ale je vidět, že ke štěstí zákeřného programátora nejsou testy úplné. Jinými slovy, pokud vám něco rcov označí červeně, je to zaručeně špatně. Pokud je to zelené, fajn, minimálně to odchytí překlepy a vyhozené výjimky, ale o kvalitě testů to neříká až tak mnoho. Nakonec se bavíme o POKRYTÍ, že?

Nemám rád dlouhé příspěvky (porucha soustředění), tak jimi ani nebudu tento svět zaplňovat. Pokračování příště.

Přednáška Tobi Lütkeho byla pro mnohé tou nejzajímavější na ostravské konferenci. Hlavní důvod byl pravděpodobně ten, že byla nejméně technická a hodně "ze života". Určitě se k ní vrátím na svém blogu (stejně jako to udělali ostatní), zde bych chtěl ale přece jen poukázat na ty techničtější body.

Shopify je podle jeho slov velmi dobře pokryto testy, používají je jako své (levné) oddělení kontroly jakosti. Zdůrazňoval především důležitost unit testů, ostatní prý mají také, ale nějak je příliš nezmiňoval. Tím vlastně prozradil, že jejich aplikace má (tak jak to má být) většinu logiky v modelech a metody v controllerech mají jen pár řádek.

Uplatňují test-first přístup, tedy nejdřív napíší test a až pak samotný výkonný kód (zatím ale nešly tak daleko, aby používaly RSpec). Před opravením chyby vždy nejprve vytvoří selhávající test ověřující daný nedostatek a až pak chybu opraví.

Pro ujištění, že všechen kód je řádně pokryt testy, používají Heckle . Tato utilitka modifikuje váš kód, spustí na něj testy a ujistí se, že selžou. Protože pokud se tak nestane, kód je buď neotestovaný nebo mrtvý. Tedy je to špatně nebo špatně. Za domácí úkol si dávám zjistit, jak se Heckle liší od rcovu, který používým nyní. Někde jsem vygooglil, že je dobré používat oboje. Jeden z rozdílu je, že Heckle dokáže ukázat, jak byl kód modifikován.

Tobiasovo ano na otázku "Does it scale?" (Shopify má kolem 1000 aktivních obchodů, celkem až 25000) bylo především o zmínce o memcached. Memcached je distribuovaná hash tabulka sídlící v paměti vašich serverů, které se můžete zeptat na data, která jste do ní uložili. Já znal jen použití pro data session uživatele (místo souborů na disku nebo ukládání do databáze), Shopify to ale evidentně používá i pro nacachované (fragmenty) stránek. Zmíněna byla i technika s jejich verzováním.

Nebudu předstírat, že to ještě úplně detailně chápu, a tak mě uklidnila zmínka, že ani nemusím začínat, dokud velikost databáze nepřekročí velikost operační paměti.

Dále již jen stručně: na deployment a údržbu samořejmě používají Capistrano, PostgresSQL má evidentně oproti MySQL nějaké problémy s replikacemi a důrazné doporučení nemít jeden bod selhání.

A to byla jen tatechničtější část (tj. cca polovina přednášky). Velmi inspirativní. Btw "If Rails doesn't fit a task then fix Rails. It's easy."