Názory k článku Univerzální testovací nástroj Robot Framework a BDD testy

Dobrý den, má vlastně význam používat například Behave, když Robot Framework nabízí víc možností? Tedy Behave podporuje víc jazyků, ale stejně to asi všichni budou psát v angličtině, takže tato jediná (?) výhoda asi není tak kritická.

Podle mě klidně použijte Robot Framework. Osobně se mi líbí oba přístupy, ať již čistě podle BDD/Behave (tedy Gherkin), tak i Robot Framework, který díky "ignorování" klíčových slov Gherkinu umožňuje +- to samé co Behave. My na projektu máme Behave, ale to spíš proto, že jsme předtím RF neznali :-)

Máte názor na pytest-bdd?

To je dobrá kombinace. Tuto knihovnu jsem sice jen zkoušel a v praxi to nemáme nasazené, ale její setup je jednodušší, než celého Behave (RF je odlišný, tam se třeba kontext řeší v rámci třídy, což mi přijde pro mnoho případů jako lepší přístup, než si hrát s parametrem context).

Robot se u nás bohužel používá, ale nejsem s ním spokojen.
Když pustím robota z shellu, tak mi neřekne na kterém řádku došlo k chybě. Když poštím testy od jiných lidí, tak trvá nepřiměřeně dloouho zkoumání co je špatně. Syntaxe jazyka je katastrofa.
Ve zkratce: robot umí 1000 věcí, které nepotřebuju, ale neumí 3 věci které potřebuju.
Špatné se googlí, example nic moc.
Mám daleko lepší zkušenosti s vlastním frameworkem, který se dá napsat na 50 řádků, použije python reflexi a dělá přesně co chci.

Můžu se zeptat, pro jaké typy testů RF používáte? Jestli se jedná o akceptační testy, nějaké BDD, web UI testy (přes Selenium atd.). Protože hodně problémů s RF nastane tehdy, pokud se začne používat ve chvíli, kdy je lepší použít například jen pytest (testy modulů, samozřejmě unit testy).

(hodně lidí používá RF IDE, ten od hodně detailů odstíní, ale já jsem CLI člověk :-)

Používáme framework pro akceptační testy.
Napr. nasledujici test:

Load < ./rules_builder_moc­k/rules_builder_moc­k.py >
Load < ./ss7/ss7.py >

Deploy Config < rules-keeping-msg-order.json >

Connect To Pep <>
Send SS7 packet from Pcap isup_5_packets.pcap 0
Send SS7 packet from Pcap isup_5_packets.pcap 1
Send SS7 packet from Pcap isup_5_packets.pcap 2
Send SS7 packet from Pcap isup_5_packets.pcap 3
Send SS7 packet from Pcap isup_5_packets.pcap 4

Check Received Pdu isup_5_packet­s.pcap_#0
Check Received Pdu isup_5_packet­s.pcap_#1
Check Received Pdu isup_5_packet­s.pcap_#2
Check Received Pdu isup_5_packet­s.pcap_#3
Check Received Pdu isup_5_packet­s.pcap_#4

Deploy Config rules-without-keeping-msg-order.json

Send SS7 packet from Pcap isup_5_packets.pcap 0
Send SS7 packet from Pcap isup_5_packets.pcap 1
Send SS7 packet from Pcap isup_5_packets.pcap 2
Send SS7 packet from Pcap isup_5_packets.pcap 3
Send SS7 packet from Pcap isup_5_packets.pcap 4

Check Received Pdu isup_5_packet­s.pcap_#0
Check Received Pdu isup_5_packet­s.pcap_#1
Check Received Pdu isup_5_packet­s.pcap_#3
Check Received Pdu isup_5_packet­s.pcap_#4
Check Received Pdu isup_5_packet­s.pcap_#2

když test havaruje, tak nezjistím na kterém řádku, a to je zásadní informace.
V logu vidím pouze něco jako:
[ ERROR ] Expected packet isup_5_packet­s.pcap_#3 didn't arrive. Actual packet is isup_5_packet­s.pcap_#2.

Diky za informaci. Jj na toto jsem taky narazil, takze musim sledovat bud JSON vystup, nebo co jde do HTML stranky (a to neni prijemne, uznavam).