Bot pro API Kalshi by si měl svůj provozní rozsah zasloužit prokázaným chováním. Úspěšné připojení nebo jedna přijatá objednávka neukazují, jak program zpracovává částečná plnění, duplicitní zprávy, změněná omezení trhu nebo pád po přenosu. Tyto případy určují, zda jeho záznam účtu zůstává důvěryhodný, když běžné předpoklady selžou.
Akceptační kritéria převádějí široká tvrzení jako spolehlivý nebo bezpečný na pozorovatelné výsledky. Určují výchozí stav účtu, vloženou událost, činnost, kterou bot smí podniknout, a očekávané následné záznamy. Test, který nedokáže uvést očekávaný ekonomický výsledek, pravděpodobně mnoho o chování bota neprokáže.
Tento průvodce předkládá hypotetické akceptační zkoušky pro autorizovaný vývojový proces. Číselné limity a ceny jsou vymyšlené. Demonstrační testování, simulované odpovědi a přehrávané záznamy mohou hodnotit chování softwaru bez prokázání produkční likvidity nebo ziskovosti strategie. Jakákoli skutečná obchodní pravomoc zůstává samostatným rozhodnutím ohraničeným pokyny vlastníka účtu.
Nejprve napište akceptační kritéria bota pro API Kalshi
Akceptační kritéria bota Kalshi by měla popisovat výsledky před podrobnostmi implementace. Například přehrání stejného plnění dvakrát musí změnit pozici jednou. Propadlý návrh se nesmí stát novou objednávkou. Ztracená odpověď musí vytvořit nevyřešený stav místo automatického uvolnění své rezervace.
Uveďte podklady vyžadované pro úspěch. Zpráva konzole, že duplicita byla ignorována, nestačí, pokud účetní kniha přesto množství započítala dvakrát. Prověřte výslednou pozici, poplatky, stav objednávky a deník. Výsledek akceptace by měl být srozumitelný někomu, kdo příslušný kód nepsal.
Starší průvodce obchodním botem v Pythonu pro API Kalshi popisuje spolehlivý návrh přesahující klienta konkrétního jazyka. Použijte tento pohled zde: důležitou vlastností je chování na hranici účtu. Volba programovacího jazyka neodstraňuje potřebu ověřit ekonomický význam.
Zajistěte známý výchozí stav účtu
Každá zkouška potřebuje výchozí stav, který lze nezávisle ověřit. Určete pozice, aktivní objednávky, dostupnou kapacitu a nevyřešené záměry. Bez známého základu lze pozdější nesoulad svést na nevysvětlenou předchozí podmínku místo testovaného chování.
Pro hypotetickou sadu začněte deseti kontrakty Ano, aktivní objednávkou pěti kontraktů a limitem třiceti kontraktů na událost. Bot by měl podle těchto jednoduchých pravidel vypočítat patnáct kontraktů existující nebo možné expozice. Nový požadavek na dvacet by překročil limit, pokud by se všechna množství stala pozicemi.
Uchovávejte tato testovací data odděleně od informací o skutečném účtu. Test by si nikdy neměl potichu vypůjčit produkční přihlašovací údaje nebo odvozovat, že známý identifikátor trhu je neškodný. Jasně určete prostředí a používejte odpovídající kontroly. Účelem je testovat ohraničené chování, nikoli objevovat stav účtu neúmyslným provedením.
Testujte přesná desetinná množství a částky
Současná dokumentace Kalshi používá ceny a množství s pevnou řádovou čárkou. Akceptace by měla zahrnovat hodnoty, které by parser celých centů nebo celých kontraktů zpracoval nesprávně, a přitom respektovat hypotetická omezení trhu použitá ve zkoušce.
Použijte vymyšlenou platnou cenu 0,3375 $ a množství 8,40 kontraktu. Jejich nákupní hodnota je 2,835 $ před poplatky. Očekávaná účetní kniha by měla uchovat přesný součin ve fázi, kde má význam, a potom samostatně použít případná zdokumentovaná konečná pravidla zaokrouhlování. Oříznutí množství na osm je selháním.
Testujte také neplatné formáty, chybějící jednotky a hodnoty mimo povolené rozsahy. Bot by měl nejednoznačné množství či částku odmítnout nebo oddělit do karantény, místo aby hádal. Parser přijímající chybné hodnoty jen proto, že dokáže vytáhnout nějaké číslice, vytváří nebezpečný rozdíl mezi tím, co vstup říká, a tím, co účet může udělat.
Testujte cenovou mřížku nezávisle na přesnosti
Desetinná hodnota může být syntakticky platná, ale mimo povolenou cenovou mřížku trhu. Bot by měl číst současná cenová omezení a ověřovat navržený limit vůči nim. Řetězec se čtyřmi desetinnými místy není automaticky platnou cenou se čtyřmi desetinnými místy pro každý trh.
V hypotetickém pásmu s kroky 0,005 $ leží zamýšlená maximální nákupní cena 0,3375 $ mezi 0,335 $ a 0,340 $. Pokud pravidla zaokrouhlují na přípustnou nákupní cenu, nesmí překročit schválené maximum. Zaokrouhlení nahoru na 0,340 $ by porušilo tento konkrétní pokyn.
Testujte změnu mřížky mezi vytvořením návrhu a odesláním. Očekávaným chováním by mělo být nové ověření, autorizovaná úprava nebo odmítnutí k prověření. Bot by neměl opakovaně odesílat neplatnou cenu s předpokladem, že každé odmítnutí je dočasným síťovým problémem.
Testujte ekonomický směr případy v běžném jazyce
Adaptér objednávek by měl správně převádět uživatelem zamýšlenou expozici vůči výsledku do směrových polí současného koncového bodu. Dokumentace směru objednávek Kalshi je referencí pro výklad současných polí odpovědí. Význam požadavků by se měl také ověřovat proti přesnému používanému koncovému bodu.
Před zkoumáním serializovaných dat napište případy lidským jazykem: zvýšit expozici vůči Ano při maximální ceně, snížit existující pozici při minimální ceně nebo vyjádřit podporované rozhodnutí na straně Ne prostřednictvím současného rozhraní. Dekódujte každý požadavek zpět do běžného jazyka a porovnejte jej s původním záměrem.
Zahrnujte případy doplňkových cen, protože mohou zakrývat chyby. Číselně věrohodná hodnota na nesprávné straně může vytvářet platnou, ale nezamýšlenou expozici. Úspěch při validaci schématu pouze dokazuje, že požadavek má přijatelnou podobu; akceptace musí také prokázat, že tato podoba nese zamýšlený ekonomický pokyn.
Testujte hranici oprávnění
Dejte botovi oprávnění pozorovat široký seznam trhů, ale obchodovat pouze malou schválenou podmnožinu. Potom mu předložte přitažlivý návrh mimo tuto podmnožinu. Očekávaným výsledkem je zaznamenané odmítnutí bez podepsané nebo přenesené objednávky.
Opakujte zkoušku s nepodporovaným typem objednávky, nadměrným množstvím a propadlou autorizací. Každý případ by měl selhat na příslušné bráně. Vysvětlení vytvořené modelem by nemělo dokázat obejít pravidla naléhavým jazykem nebo tvrzením o neobvykle vysoké jistotě.
Průvodce automatizací Polymarket porovnává ruční, dozorované a delegované pracovní postupy. Jeho užitečným obecným poučením je, že pravomoc musí být v každé fázi výslovná. U tohoto bota Kalshi by akceptační záznam měl přesně ukázat, která činnost byla zamítnuta a jaké pozorování nebo ověřování a slaďování zůstalo povoleno.
Testujte souběžné návrhy vůči jednomu limitu
Dva návrhy mohou projít jednotlivě a společně překročit sdílený limit. Akceptace by je měla vložit dostatečně blízko v čase, aby odhalila souběh kontroly kapacity a zaznamenávání rezervací. Očekávaným chováním je koordinovaná autorizace, nikoli dvě nezávislá schválení založená na stejné zastaralé momentce stavu.
Vraťte se k hypotetickému limitu třiceti kontraktů s patnácti již drženými nebo zavázanými. Dva návrhy žádají každý deset. Pokud pravidla hodnotí nejhorší možné vyplněné množství, vejde se pouze jeden přírůstek deseti kontraktů; druhý by zvýšil potenciální expozici na třicet pět. Bot musí druhý návrh odmítnout, změnit jeho velikost podle autorizovaných pravidel nebo jej odložit.
Po obou rozhodnutích prověřte sdílenou účetní knihu. Měla by obsahovat jeden konzistentní součet rezervací a důvod odloženého nebo odmítnutého návrhu. Test by neměl projít jen proto, že pozdější odmítnutí obchodním místem náhodou zabránilo překročení. Vlastní autorizační hranice aplikace musí fungovat.
Testujte idempotentní zpracování plnění
Idempotentní zpracování plnění znamená, že přijetí stejného ekonomického plnění více než jednou má stejný účinek na účet jako jediné přijetí. Datové proudy, opětovná připojení a pozdější dotazy na účet mohou všechny dodávat překrývající se podklady. Bot musí rozpoznávat stejné plnění podle stabilní identity a zdokumentovaných pravidel revizí.
Začněte deseti kontrakty a vložte plnění čtyř kontraktů. Výsledná pozice je čtrnáct. Přehrajte stejné plnění druhou cestou; výsledek by měl zůstat čtrnáct a související poplatek má být zaznamenán jednou. Druhé odlišné plnění čtyř kontraktů by pak mělo vytvořit osmnáct.
Tento test rozlišuje duplicitní přenos od opakovaného oprávněného obchodování. Odstraňování duplicit pouze podle množství a ceny by nesprávně zahodilo samostatná plnění, která náhodou mají totožné podmínky. Záznam potřebuje identifikátory a údaje o původu dostatečně silné k zachování skutečných provedení a potlačení opakovaných pozorování téhož.
Testujte částečná plnění a stav zbytku
Částečné plnění by mělo aktualizovat držby o provedené množství a zachovat správný stav nevyplněné části. Na zvoleném chování doby platnosti záleží. Čekající zbytek a zrušený okamžitý zbytek jsou různé závazky účtu, i když je vyplněné množství totožné.
V hypotetické objednávce dvanácti kontraktů se pět provede za 0,40 $, s náklady 2 $ před poplatky. Sedm zůstává nevyplněných. Jedna zkouška ponechává těchto sedm aktivních; jiná je ukončuje podle zvoleného zdokumentovaného chování okamžité objednávky. Očekávané panely rezervací a objednávek by se měly odpovídajícím způsobem lišit.
Bot by nikdy neměl vyvozovat, že každé částečné plnění vytváří aktivní zbytek. Měl by se také vyhnout tomu, aby považoval zrušený zbytek za zrušení provedených pěti. Kontrolujte společně pozici, nákupní náklady, poplatky a konečný stav objednávky, aby test ověřoval úplný ekonomický výsledek.
Doporučujte a vydělávejte USDC
Doporučujte a vydělávejte USDCNáš partnerský program vyplácí v reálném čase.
Testujte ztracenou odpověď na odeslání
Simulujte přenos objednávky následovaný ztrátou odpovědi. V jednom případě ji obchodní místo přijalo; v jiném ji odmítlo. Bot má zpočátku stejný místní příznak, takže jeho první reakce by měla zachovat nejistotu a prošetřit původní záměr.
Očekávané chování zahrnuje zachování příslušné rezervace, vyhnutí se nové nesouvisející objednávce a nahlédnutí do podporovaných záznamů objednávek a plnění. Test by měl ověřit, že prázdný seznam otevřených objednávek sám neuzavře případ, pokud se objednávka mohla zcela provést.
Klientský identifikátor objednávky může pomoci spojit záznamy, ale bot musí ověřit současná pravidla zpracování duplicit obchodního místa, místo aby předpokládal neomezené provedení právě jednou. Místní idempotentní zpracování, identita požadavku a záruky vzdáleného přijetí jsou příbuzné nástroje s různými rozsahy. Akceptační kritéria by měla uvádět, která záruka je skutečně testována.
Testujte pád po přijetí
Zvlášť užitečná zkouška obnovy po restartu zastaví proces poté, co obchodní místo přijme objednávku, ale před uložením místního záznamu úspěchu. Při restartu by měl bot načíst svůj trvalý záměr a ověřit a sladit vzdálený stav, než rozhodne, zda je vůbec třeba něco odeslat.
Pokud jednoduše přehraje každý záměr bez místního příznaku dokončení, může vytvořit duplicitní expozici. Očekávaným výsledkem obnovy je jedna ekonomická objednávka propojená s původním záměrem, přičemž každé aktivní množství nebo provedení je promítnuto v účetní knize účtu. Pokud dostupné podklady nedokážou vztah zjistit, výsledek by měl zůstat výslovně nevyřešený.
Starší průvodce botem pro automatické obchodování Kalshi vysvětluje provozní stavy. Restart by měl být přechodem přes pozorování a ověřování a slaďování, nikoli automatickým skokem do neomezeného obchodování. Akceptace by měla prověřit tento přechod, místo aby pouze potvrdila, že proces úspěšně nastartuje.
Testujte rušení během plnění
Vložte plnění v průběhu rušení. Bot by měl ověřit a sladit provedené množství a část, která byla skutečně odstraněna. Požadavek na zrušení vyjadřuje záměr; zpětně nezabraňuje plnění, které již nastalo.
U vymyšleného aktivního zbytku devíti kontraktů předpokládejte provedení tří předtím, než zrušení odstraní ostatních šest. Pozice účtu se zvýší o tři a závazek spojený se šesti končí. Náhradní návrh by měl používat tento výsledný stav místo předpokladu, že bylo zrušeno všech devět.
Kontrolujte vysvětlení operátorovi i čísla. Rozhraní by mělo ukazovat, proč se konečná pozice liší od množství viditelného při zahájení rušení. Obecný štítek zrušeno může skrýt dodatečné plnění a podpořit nadměrné nahrazení, i když podkladová účetní kniha náhodou obsahuje správné množství.
Testujte změněný stav trhu
Návrh může být při vytvoření platný a při dosažení odeslání neplatný. Vložte mezi tyto fáze pozastavení, uzavření nebo změněné omezení trhu. Očekávané chování by se mělo řídit současnými pravidly obchodního místa a aplikace, bez pokusu obejít stav opakovanými požadavky.
Dokumentace životního cyklu trhu Kalshi popisuje současné fáze obchodování a vypořádání. Akceptační sada by měla používat jejich význam, místo aby předpokládala, že jeden obecný příznak otevřeno nebo zavřeno pokrývá každou povinnost.
Výzkum může pokračovat při zakázaném vytváření objednávek a ověřování a slaďování může zůstat nezbytné po skončení obchodování. Testujte tyto schopnosti samostatně. Bot, který při uzavření trhu zastaví veškeré pozorování účtu, může zmeškat právě záznamy potřebné k určení konečných pozic, poplatků a vypořádání. Provozní omezení by měla zužovat činnosti, aniž mažou povinnost zachytit předchozí činnosti v účtu.
Testujte výpadky proudů a překrývající se načtení obnovy
Odpojte soukromý datový proud během plnění, potom jej znovu připojte a načtěte historii účtu. Proces obnovy může narazit na plnění již viděná před výpadkem i na nová. Očekávaná účetní kniha by měla zahrnout každou ekonomickou událost jednou a určit obnovený interval.
Užitečná zkouška vrací záznamy v nepohodlném pořadí. Opožděná aktualizace by neměla přepsat novější stav jen proto, že místně přišla později. Při určování vztahu mezi záznamy uchovávejte identifikátory událostí, příslušné časové značky a zdokumentované informace o verzích.
Pokud nelze zjistit úplné pokrytí, měl by bot zachovat výjimku a omezit novou expozici podle svých pravidel. Přesně vypadající pozice odvozená z neúplného proudu není úspěšnou obnovou. Test projde, pokud je výsledek buď ověřený, nebo poctivě nevyřešený, s jasným dalším krokem.
Testujte limity četnosti bez změny záměru
Načtení nebo zápis omezené limitem četnosti by neměly způsobit změnu ekonomického významu požadavku botem. Čekání před opakováním může změnit načasování, ale nesmí potichu zvýšit množství, rozšířit limit nebo vytvořit nový nezávislý záměr. Opožděné návrhy mohou během čekání vypršet.
Procvičujte běžné omezování tržních dat i soukromý požadavek na ověření a sladění potřebný k vyřešení nejistoty. Bot by měl upřednostňovat podle svých provozních pravidel a zachovat dostatek kapacity pro nezbytné pozorování účtu, pokud to rozhraní umožňuje. Neměl by utratit všechny dostupné požadavky za málo hodnotná obnovení kotací.
Zaznamenávejte skutečné zpoždění do výzkumné historie a historie provedení. Strategie nemůže tvrdit, že získala původní kotaci, pokud omezování četnosti odložilo její rozhodnutí. Výsledek akceptace by měl ukazovat, že zastaralé návrhy byly znovu ověřeny nebo odmítnuty a že nevyřešená odeslání zůstala spojena s původními rezervacemi.
Testujte selhání přihlašovacích údajů jako kontrolovaný stav
Propadlé, odvolané nebo nesprávně nastavené přihlašovací údaje by měly vytvářet jasný stav ztráty schopnosti. Bot by se měl vyhnout odhalování tajných údajů v chybových zprávách a neměl by přejít na nezamýšlený účet nebo prostředí jen proto, aby požadavek uspěl.
Rozlišujte veřejné pozorování od soukromého přístupu. Obrazovka tržních údajů může nadále fungovat, zatímco načtení účtu a činnosti objednávek selhávají. Rozhraní by mělo tento rozdíl vysvětlovat, aby operátor nevyvozoval, že pohyblivé zobrazení ceny dokazuje zdravé obchodní spojení.
Průvodce obchodní platformou Kalshi rozebírá přístup k účtu a provozní použitelnost. Akceptace by měla zahrnovat to, co čtenář vidí při selhání přihlašovacích údajů: dotčená oprávnění, poslední ověřený čas účtu a nevyřešené závazky. Obecný štítek odpojeno nestačí, pokud skrývá, které povinnosti lze stále dokončit.
Testujte rozhraní pro lidské prověření
Bot může udržovat správné vnitřní záznamy a přesto mást operátora špatnou prezentací. Testujte, zda obrazovka rozlišuje stavy navrženo, autorizováno, odesláno, aktivní, provedeno a ověřeno a sladěno. Ukazujte částečná množství a nevyřešené položky bez požadavku, aby čtenář vykládal surové protokoly.
Požádejte posuzovatele, aby vysvětlil vymyšlený incident pouze ze zobrazeného záznamu. Měl by určit kontrakt, možnou expozici, poslední ověřené podklady a další činnost. Pokud to nedokáže, akceptační sada našla problém použitelnosti, který se pod tlakem může stát provozním problémem.
Srovnání s obchodní platformou Polymarket pomáhá oddělit obecné povinnosti rozhraní od mechanismů obchodního místa. Jasné informace o úschově, objednávkách a vypořádání jsou důležité v obou kontextech, ale štítky musejí popisovat skutečný model účtu. Sdílený vizuální návrh by neměl vytvářet dojem, že odlišné stavy jsou ekonomicky totožné.
Verzujte podklady akceptace
Ukládejte scénář, verzi klienta, nastavení a pozorovaný výsledek každého běhu akceptace. Pozdější změnu kódu nebo schématu pak lze porovnat se známým základem. Bez verzovaných podkladů se tvrzení, že bot prošel testováním, může vztahovat k nastavení, které se již nepoužívá.
Soustřeďte regresní kontroly na smysluplné hranice: množství a částky, směr, oprávnění, duplicitní zpracování a obnovu. Stonásobné opakování úspěšného běžného testu spojení přidává málo, pokud migrace změnila pole určující, zda objednávka kupuje nebo prodává zamýšlený výsledek.
Starší průvodce obchodním API pro predikční trhy vysvětluje připojení a ověření jako rozdílné povinnosti. Podklady akceptace by podobně měly rozlišovat dostupnost rozhraní od správného chování celého pracovního postupu účtu. Obojí jsou užitečné skutečnosti, ale pouze jedna řeší obtížné provozní případy.
Udělte botovi pro API Kalshi jen rozsah, kterým prošel
Akceptace je podkladem pro ohraničené provozní rozhodnutí. Bot, který projde testy ověřování a slaďování pouze pro čtení, automaticky neprokázal obnovu skutečných objednávek. U bota testovaného na jednom typu objednávky není jisté, že zvládl každou jinou dobu platnosti nebo konfiguraci účtu.
Dokumentujte schválený rozsah, známá omezení a podmínky vyžadující nové prověření. Rozšíření by mělo následovat nové podklady: další pokrytí scénářů, ověření současného schématu a jasná pravidla účtu. Zachovejte možnost zůstat v pozorovacím nebo dozorovaném režimu, pokud je případ obnovy stále nevyřešený.
Nejužitečnějším výsledkem akceptace je přesné vyjádření prokázaného chování. Ukazuje, že bot zachovává jednotky, respektuje pravomoc, zpracovává plnění jednou a rekonstruuje stav účtu po určených selháních. Tyto podklady jsou informativnější než široký štítek spolehlivosti a dávají operátorovi konkrétní základ pro rozhodnutí, jakou práci smí program vykonávat dál.