CLI alkalmazás Rustban: bemenet, hibakód és tesztek egy kis projektben

Egy kicsi programnak is legyen világos szerződése

A példánk egy fájlt kap, és kiírja a sorok számát. Egy argumentumot vár, a szabványos kimenetre csak a sikeres eredmény kerül, a hibaüzenet a szabványos hibakimenetre megy. A kilépési kód siker esetén nulla, használati hibánál kettő, olvasási hibánál egy. Ezek itt a saját eszközünk dokumentált döntései; nem minden CLI használja ugyanezt a felosztást.

Ez a kis szerződés azért hasznos, mert a parancsot később shellből vagy CI-ból is meg lehet hívni. Az ember számára olvasható hibaüzenet nem helyettesíti a géppel ellenőrizhető kódot. A Cargo: build, run, test lecke adja a fejlesztési kört, a Hello, rustacean! gyakorlat pedig az első futtatható program kiindulópontja.

Válaszd szét a döntést és a folyamat indítását

A kísérő projekt könyvtárfüggvénye argumentumokból és egy beolvasó függvényből állít elő eredményt. A main csak összeköti az operációs rendszer argumentumait, a fájlolvasást és a kimeneteket. Ezzel a hibák teszteléséhez nem kell valódi fájlt létrehozni minden esetben. A folyamat teljes viselkedését ettől még külön integrációs próba ellenőrzi.

A fájlnévhez args_os() értékeit használjuk, mert egy operációsrendszerbeli útvonal nem feltétlenül alakítható veszteség nélkül UTF-8 Stringgé. A szabványos könyvtár dokumentációja leírja a különbséget. A fájl tartalmára viszont ez az eszköz kifejezetten UTF-8 szerződést vállal; bináris állományhoz más feldolgozás kellene.

cargo test --locked
cargo run --locked -- pelda.txt
cargo build --release --locked

A -- a Cargo argumentumai és a program saját argumentumai közé kerül. A release build előállítja a binárist, de nem hoz létre automatikusan minden operációs rendszeren kipróbált kiadást. Keresztfordításkor a célplatformhoz szükséges linker és rendszerfüggőségek is részei a környezetnek.

A hibaút ugyanúgy a funkció része

Hiányzó argumentumnál ne essünk panicba, és ne olvassunk önkényes alapértelmezett fájlt. Nem létező fájlnál a felhasználó kapjon érthető üzenetet. A main a std::process::ExitCode segítségével adja vissza az eredményt. A hibaszöveg a hibafajtát közölje; ha naplózod, kerüld a szükségtelen teljes bemenetet vagy érzékeny fájltartalmat.

A sorok számát a példában a String lines() iterátora határozza meg. Ennek a dokumentált működése fontos az üres fájlnál és a záró sortörésnél. Mielőtt egy másik eszköz eredményével hasonlítod össze, egyeztesd a sor fogalmát: például az utolsó sortörés hiánya különbséget okozhat eltérő számlálási szabályoknál.

Mit érdemes tesztelni a kiadás előtt?

A kísérő projekt ellenőrzi az üres bemenetet, a több sort, a záró sortörést, a hiányzó és a túl sok argumentumot, valamint a beolvasási hibát. A külön folyamatként futó teszt a stdout, stderr és kilépési kód kombinációját vizsgálja. Így azt is észreveszi, ha valaki később a sikeres kimenetre ír egy hibakereső üzenetet.

Ha az eszköz több alparancsot vagy összetett kapcsolókat kap, indokolt lehet argumentumfeldolgozó könyvtárra váltani. Előbb azonban a viselkedést rögzítsd; egy új könyvtár nem dönt helyetted az üres bemenet, a fájlkódolás vagy a hibaüzenetek szabályairól. A minta Rust 1.97.1, edition 2024 környezeten futtatható, külső függőség nélkül, ezért jó alap a saját változatod elkészítéséhez.