Testiaineistot, väliaikaisympäristöt ja kattavuus
Rakenna eristettyjä testiaineistoja ja mittaa, mitä skriptin haaroja testisi todella suorittavat.
Testiaineistot, väliaikaisympäristöt ja kattavuus on ilmainen Linux-komentorivin ja Bash-komentosarjojen hallinta-oppitunti CoddyKitissä. Tämä on oppitunti 3/4. Voit lukea koko oppitunnin alta ilmaiseksi ja harjoitella sen jälkeen käytännössä selaimessa sisäänrakennetulla koodieditorilla ja ympäri vuorokauden käytettävissä olevan tekoälytuutorin avulla. Oppitunti kuuluu Linux-komentorivin ja Bash-komentosarjojen hallinta-oppimispolkuun, ja edistymisesi synkronoituu verkon ja CoddyKit-sovelluksen välillä. Linux-komentorivin ja Bash-komentosarjojen hallinta-kurssilla on yhteensä 4 oppituntia.
Miksi testidatat ja eristys ovat tärkeitä
Bash-skriptejä testattaessa suurin riski ovat sivuvaikutukset: testinne muuttavat vahingossa oikeita tiedostoja, tietokantoja tai järjestelmän todellista tilaa. Testi, joka menee koneellanne läpi mutta turmelee tuotantodataa, on pahempi kuin testien puuttuminen kokonaan.
Ratkaisu on testidata — hallitut ja hävitettävät ympäristöt, jotka jäljittelevät todellisia olosuhteita koskematta oikeisiin resursseihin. Hyvä testidata tarjoaa seuraavat ominaisuudet:
- Toistettavuus — testit tuottavat saman tuloksen joka ajokerralla
- Eristys — testit eivät häiritse toisiaan eivätkä isäntäympäristöä
- Turvallisuus — tuhoisat operaatiot kohdistuvat vain hävitettävään dataan
- Nopeus — verkkokutsuja tai raskasta I/O:ta ei käytetä, ellei se ole ehdottoman välttämätöntä
Bash-testauksessa testidata koostuu yleensä väliaikaishakemistoista, joihin on sijoitettu tunnetut tiedostot, $PATH-muuttujan alkuun sijoitetuista mock-suoritettavista tiedostoista sekä testiprosessiin rajatuista ympäristömuuttujista.
Väliaikaishakemistojen luominen ja siivoaminen
Testikohtaisen väliaikaishakemiston vakiomalli käyttää komentoa mktemp -d. Se luo yksilöllisen hakemiston hakemistoon /tmp ja tulostaa sen polun. Polku tallennetaan, ja hakemiston automaattista poistamista varten rekisteröidään trap, joka suoritetaan shellin lopettaessa — myös virhetilanteessa.
Tämän kaksirivisen idiomin pitäisi olla jokaisessa tiedostojärjestelmää käyttävässä testitiedostossa:
#!/usr/bin/env bash
set -euo pipefail
# Create an isolated temp directory
TMPDIR=$(mktemp -d)
# Always clean up, even if the script exits early or errors out
trap 'rm -rf "$TMPDIR"' EXIT
echo "Working in: $TMPDIR"
# Simulate creating fixture files
mkdir -p "$TMPDIR/project/{src,tests,logs}"
echo 'version=1.2.3' > "$TMPDIR/project/.env"
echo 'Hello fixture' > "$TMPDIR/project/src/main.sh"
ls -R "$TMPDIR/project"
echo 'Temp dir will be removed automatically on exit'Testidatan hakemistopuun jäsentäminen
Hyvin jäsennelty testidata jäljittelee hakemistorakennetta, jota testattava skriptinne todella odottaa. Ajatelkaa sitä pienenä väärennettynä projektin juurihakemistona. Testidatan valmistelufunktio luo tämän rakenteen ennen jokaista testiä, ja purku poistaa sen.
Keskeiset käytännöt:
- Käyttäkää
setup()-funktiota, jonka testikehys kutsuu ennen jokaista testiä - Käyttäkää
teardown()- taicleanup()-funktiota, joka suoritetaan jokaisen testin jälkeen myös virhetilanteessa - Pitäkää testidatatiedostot minimaalisina — mukana saa olla vain se, minkä skripti todella lukee
- Nimetkää testidatatiedostot kuvaavasti, jotta virheiden diagnosointi on helppoa
#!/usr/bin/env bash
# fixture_helpers.bash — source this from your test files
FIXTURE_ROOT=''
setup_fixture() {
FIXTURE_ROOT=$(mktemp -d)
# Build the directory tree the deploy script expects
mkdir -p "$FIXTURE_ROOT"/{dist,config,logs}
echo '{"version":"2.0"}' > "$FIXTURE_ROOT/config/app.json"
echo 'console.log("app")' > "$FIXTURE_ROOT/dist/index.js"
touch "$FIXTURE_ROOT/logs/.gitkeep"
export FIXTURE_ROOT
echo "[setup] Fixture ready at $FIXTURE_ROOT"
}
teardown_fixture() {
if [[ -n "$FIXTURE_ROOT" && -d "$FIXTURE_ROOT" ]]; then
rm -rf "$FIXTURE_ROOT"
echo '[teardown] Fixture removed'
fi
}
# Self-test
setup_fixture
ls "$FIXTURE_ROOT"
teardown_fixtureSuoritettavien tiedostojen mockaaminen väärennetyllä PATH-muuttujalla
Monet Bash-skriptit kutsuvat ulkoisia työkaluja, kuten curl, aws, docker tai git. Testeissä ette halua käyttää oikeita palveluita, joten korvaatte nämä työkalut väärennetyillä suoritettavilla tiedostoilla.
Tekniikka on yksinkertainen:
- Luokaa testidatan sisälle väliaikainen
bin/-hakemisto - Kirjoittakaa sinne pieniä shell-skriptejä, joilla on samat nimet kuin oikeilla työkaluilla
- Lisätkää hakemisto
$PATH-muuttujan alkuun ennen testattavan skriptin kutsumista
Koska $PATH-muuttujaa etsitään vasemmalta oikealle, väärennetty tiedosto voittaa. Oikeaa binääritiedostoa ei koskaan suoriteta.
#!/usr/bin/env bash
set -euo pipefail
FIXTURE=$(mktemp -d)
trap 'rm -rf "$FIXTURE"' EXIT
# Create a fake 'curl' that records calls and returns canned data
FAKE_BIN="$FIXTURE/bin"
mkdir -p "$FAKE_BIN"
cat > "$FAKE_BIN/curl" << 'SCRIPT'
#!/usr/bin/env bash
# Log every argument for later inspection
echo "curl $*" >> "$FIXTURE_BIN_LOG"
# Return a canned HTTP 200 response body
echo '{"status":"ok","id":42}'
SCRIPT
chmod +x "$FAKE_BIN/curl"
# Export the log path so the fake can find it
export FIXTURE_BIN_LOG="$FIXTURE/curl_calls.log"
# Prepend fake bin directory to PATH
export PATH="$FAKE_BIN:$PATH"
# Now any call to 'curl' hits our fake
curl -s https://api.example.com/health
curl -X POST https://api.example.com/deploy
echo '--- Recorded curl calls ---'
cat "$FIXTURE_BIN_LOG"Komennon tulosteen tallentaminen ja tarkistaminen
Testidata on hyödyllistä vain, jos voitte tarkistaa, mitä skriptinne teki. Vakiintuneita tapoja ovat:
- Tallentakaa stdout- ja stderr-tulosteet muuttujiin syntaksilla
$()tai prosessisubstituutiolla - Tarkastakaa väärennettyjen binääritiedostojen kirjoittamat lokitiedostot
- Tarkistakaa päättymiskoodit eksplisiittisesti syntaksilla
$?tai ehdollisella logiikalla - Varmistakaa, että tietyt tiedostot luotiin, muuttuivat tai jäivät koskemattomiksi
Pienet ja tarkasti rajatut tarkistusapuohjelmat tekevät testeistä helposti luettavia ja tuottavat täsmälliset virheilmoitukset, kun jokin menee pieleen.
#!/usr/bin/env bash
set -euo pipefail
# Minimal assertion helpers
assert_eq() {
local desc="$1" expected="$2" actual="$3"
if [[ "$expected" == "$actual" ]]; then
echo "PASS: $desc"
else
echo "FAIL: $desc"
echo " expected: $expected"
echo " actual: $actual"
return 1
fi
}
assert_file_exists() {
local desc="$1" file="$2"
if [[ -f "$file" ]]; then
echo "PASS: $desc"
else
echo "FAIL: $desc — file not found: $file"
return 1
fi
}
assert_contains() {
local desc="$1" needle="$2" haystack="$3"
if [[ "$haystack" == *"$needle"* ]]; then
echo "PASS: $desc"
else
echo "FAIL: $desc — '$needle' not found in output"
return 1
fi
}
# Demo usage
TMPDIR=$(mktemp -d)
trap 'rm -rf "$TMPDIR"' EXIT
echo 'hello world' > "$TMPDIR/greeting.txt"
OUT=$(cat "$TMPDIR/greeting.txt")
assert_eq 'file content matches' 'hello world' "$OUT"
assert_file_exists 'greeting file created' "$TMPDIR/greeting.txt"
assert_contains 'output has hello' 'hello' "$OUT"Ympäristömuuttujien rajaus testeissä
Skriptit lukevat usein ympäristömuuttujia, kuten $HOME, $CONFIG_PATH tai $DATABASE_URL. Testeissä nämä on ylikirjoitettava saastuttamatta oikeaa ympäristöä.
Turvallisin tapa on suorittaa testattava skripti alishellissä, jossa on vain eksplisiittisesti asetetut muuttujat. Komennolla env voitte tyhjentää ympäristön ja lisätä takaisin vain tarvitsemanne muuttujat:
env -i VAR=val ./script.sh— täysin puhdas ympäristö(export VAR=val; ./script.sh)— alishelli perii emo-prosessin ympäristön ja lisää siihen tekemänne ylikirjoitukset
Alishellien käyttäminen tarkoittaa myös, että jos skripti muuttaa muuttujaa $IFS, $PWD tai muuta globaalia tilaa, muutokset eivät koskaan pääse takaisin testiajoon.
#!/usr/bin/env bash
set -euo pipefail
FIXTURE=$(mktemp -d)
trap 'rm -rf "$FIXTURE"' EXIT
# Write a tiny script under test that reads env vars
cat > "$FIXTURE/deploy.sh" << 'SCRIPT'
#!/usr/bin/env bash
set -euo pipefail
ENV_NAME=${DEPLOY_ENV:-unknown}
CFG=${CONFIG_DIR:-/etc/app}
echo "Deploying to $ENV_NAME using config from $CFG"
SCRIPT
chmod +x "$FIXTURE/deploy.sh"
echo '--- Test 1: staging env ---'
# Run in a clean subshell with explicit vars
(
export DEPLOY_ENV=staging
export CONFIG_DIR="$FIXTURE/config"
"$FIXTURE/deploy.sh"
)
echo '--- Test 2: production env ---'
(
export DEPLOY_ENV=production
export CONFIG_DIR=/etc/prod-config
"$FIXTURE/deploy.sh"
)
echo '--- Test 3: defaults ---'
# No env vars set — script should use its own defaults
env -i PATH="$PATH" "$FIXTURE/deploy.sh"kcov-esittely Bash-kattavuuden mittaamiseen
Kattavuus vastaa kysymykseen: mitkä skriptini rivit (ja haarat) testit todella suorittivat? Suuri kattavuusluku ei takaa oikeellisuutta, mutta pieni kattavuus paljastaa testaamattomia polkuja, joissa on todennäköisesti virheitä.
Bashin kattavuuden päätyökalu on kcov. Se instrumentoi skriptin käyttöjärjestelmätasolla käyttäen PTRACE-tekniikkaa (Linux) tai dtrace-tekniikkaa (macOS), joten lähdekoodiin ei tarvitse tehdä muutoksia. Se tuottaa HTML-raportin, jossa peittämättömät rivit näkyvät punaisina ja suoritetut rivit vihreinä.
Peruskäyttö:
kcov --include-path=./src coverage-out/ ./src/myscript.sh- Avatkaa
coverage-out/index.htmlselaimessa tulosten tarkastelemista varten - Jäsentäkää CI:ssä tiedosto
coverage-out/myscript.sh/coverage.jsonkoneellisesti luettavan prosenttiosuuden saamiseksi
Huomautus: kcov on asennettava erikseen (brew install kcov macOS:ssä, apt install kcov Ubuntu 20.04+:ssa).
kcov:n suorittaminen oikeaa skriptiä vasten
Tässä on päästä päähän ulottuva esimerkki, joka näyttää käyttöönotettavan skriptin, sitä suorittavan testin sekä kattavuutta mittaavan kcov-kutsun. Huomaatte, että tuloshakemisto on testikohtainen, joten voitte myöhemmin yhdistää useiden testiajojen tulokset.
#!/usr/bin/env bash
# This demo shows the *structure* of a kcov workflow.
# It will not run kcov itself (not guaranteed to be installed),
# but the script under test and test runner are fully runnable.
set -euo pipefail
FIXTURE=$(mktemp -d)
trap 'rm -rf "$FIXTURE"' EXIT
# 1. Script under test
cat > "$FIXTURE/process.sh" << 'SCRIPT'
#!/usr/bin/env bash
set -euo pipefail
INPUT="$1"
if [[ ! -f "$INPUT" ]]; then
echo "ERROR: file not found" >&2
exit 1
fi
LINE_COUNT=$(wc -l < "$INPUT")
if (( LINE_COUNT == 0 )); then
echo "WARNING: file is empty"
else
echo "Processed $LINE_COUNT lines"
fi
SCRIPT
chmod +x "$FIXTURE/process.sh"
# 2. Happy path test (exercises line 6 and 11)
echo -e 'one\ntwo\nthree' > "$FIXTURE/data.txt"
OUT=$("$FIXTURE/process.sh" "$FIXTURE/data.txt")
echo "Happy path: $OUT"
# 3. Empty file test (exercises line 9)
touch "$FIXTURE/empty.txt"
OUT=$("$FIXTURE/process.sh" "$FIXTURE/empty.txt")
echo "Empty file: $OUT"
# 4. Missing file test (exercises line 5-6)
if ! OUT=$("$FIXTURE/process.sh" "$FIXTURE/missing.txt" 2>&1); then
echo "Missing file (expected error): $OUT"
fi
# To measure coverage, wrap each call with kcov:
# kcov --include-path="$FIXTURE" "$FIXTURE/cov/happy" "$FIXTURE/process.sh" ...
# kcov --merge "$FIXTURE/cov/all" "$FIXTURE/cov/happy" "$FIXTURE/cov/empty"Useiden testiajojen kattavuuden yhdistäminen
Yksi testi kattaa harvoin kaikki haarat. Suoritatte useita testejä — jokaisen omaan kattavuustulosten hakemistoonsa — ja sitten yhdistätte tulokset. kcov:n --merge-valitsin yhdistää useat ajot yhdeksi yhtenäiseksi raportiksi.
CI-putken tyypillinen malli:
- Suorittakaa testi A → tulos hakemistoon
cov/test_a/ - Suorittakaa testi B → tulos hakemistoon
cov/test_b/ - Yhdistäkää tulokset →
kcov --merge cov/all/ cov/test_a/ cov/test_b/ - Jäsentäkää
cov/all/<script>/coverage.jsonlopullisen prosenttiosuuden saamiseksi
Voitte myös pakottaa vähimmäiskattavuuden ja epäonnistuttaa CI-koonnin, jos kattavuus laskee sen alle:
#!/usr/bin/env bash
# extract_coverage.sh — parse kcov JSON and fail below threshold
set -euo pipefail
MIN_COVERAGE=80 # percent
COV_JSON="${1:-coverage-out/myscript.sh/coverage.json}"
if [[ ! -f "$COV_JSON" ]]; then
echo "ERROR: coverage JSON not found at $COV_JSON" >&2
exit 1
fi
# kcov JSON contains a key like: "percent_covered": "87.50"
PERCENT=$(grep -oP '"percent_covered":\s*"\K[0-9.]+' "$COV_JSON")
PERCENT_INT=${PERCENT%%.*} # truncate decimal
echo "Coverage: ${PERCENT}% (minimum: ${MIN_COVERAGE}%)"
if (( PERCENT_INT < MIN_COVERAGE )); then
echo "FAIL: coverage ${PERCENT}% is below threshold ${MIN_COVERAGE}%" >&2
exit 1
fi
echo "PASS: coverage threshold met"Haarakattavuus ja rivikattavuus
Käytössä on kaksi keskeistä kattavuusmittaria:
- Rivikattavuus — suoritettiinko tämä rivi lainkaan? Sitä on helppo manipuloida: yksi testi voi osua moniin riveihin mutta jättää tärkeät ehdolliset polut kattamatta.
- Haarakattavuus — suoritettiinko jokainen
if-,case- ja&&/||-rakenteen haara? Tämä on paljon vahvempi mittari. Se edellyttää testejä jokaisen päätöksen sekä tosi- että epätosipuolelle.
kcov raportoi molemmat. Keskeinen havainto on, että 100 %:n rivikattavuus ei tarkoita 100 %:n haarakattavuutta. Tarkastellaan tätä skriptiä — yksi testi, jossa tiedosto ei ole tyhjä, kattaa kaikki rivit, mutta tyhjän tiedoston haaraa (alla oleva rivi 9) ei koskaan saavuteta:
#!/usr/bin/env bash
# Illustrates line vs branch coverage gap
set -euo pipefail
check_file() {
local f="$1"
if [[ -f "$f" ]]; then # branch A (true) OR branch B (false)
local lines
lines=$(wc -l < "$f")
if (( lines > 0 )); then # branch C (true) OR branch D (false)
echo "File has $lines lines"
else
echo "File is empty" # branch D — unreached if only tested with non-empty file
fi
else
echo "File missing" # branch B — unreached if only tested with existing file
fi
}
# Only one test: covers lines 5-10 (4 of 6 branches)
TMPDIR=$(mktemp -d)
trap 'rm -rf "$TMPDIR"' EXIT
echo 'data' > "$TMPDIR/sample.txt"
check_file "$TMPDIR/sample.txt"
# To reach 100% branch coverage you also need:
# check_file "/nonexistent/path"
# check_file "$TMPDIR/empty.txt" (after: touch "$TMPDIR/empty.txt")Testifiktuurien ja kattavuuden integrointi CI-putkeen
Kun kaikki kootaan yhteen: Bash-projektien vankka CI-putki yhdistää testifiktuurien valmistelun, testien suorittamisen kcov:n alla, yhdistämisen ja kynnysarvon tarkistamisen yhdeksi skriptiksi. Tästä skriptistä tulee CI:n lähtöpiste — yksi komento suorittaa kaiken.
CI-testiajurin suunnitteluperiaatteet:
- Jokainen testitapaus kutsuu funktiota
setup_fixtureja rekisteröi funktionteardown_fixturekomennollatrap - Testattava skripti kutsutaan käyttäen vale-
$PATH-arvoa ja rajattuja ympäristömuuttujia - kcov ympäröi jokaisen kutsun ja kirjoittaa tulokset numeroituun alihakemistoon
- Kaikkien testien jälkeen kcov yhdistää tulokset, ja kynnysarvoskripti estää koontiversion hyväksymisen tarvittaessa
- CI-ajuri päättyy nollasta poikkeavaan paluuarvoon, jos jokin testi tai kattavuustarkistus epäonnistuu
#!/usr/bin/env bash
# ci_runner.sh — full fixture + coverage pipeline entry point
set -euo pipefail
SRC="./src/deploy.sh"
COV_ROOT="$(mktemp -d)/coverage"
trap 'rm -rf "$COV_ROOT"' EXIT
mkdir -p "$COV_ROOT"
PASS=0
FAIL=0
RUN_NUM=0
run_test() {
local name="$1" test_fn="$2"
local fixture
fixture=$(mktemp -d)
local cov_out="$COV_ROOT/run_$((++RUN_NUM))"
if (
trap 'rm -rf "$fixture"' EXIT
export FIXTURE="$fixture"
# Fake bin directory shadowing real tools
mkdir -p "$fixture/bin"
export PATH="$fixture/bin:$PATH"
"$test_fn" "$fixture"
); then
echo "PASS: $name"
(( PASS++ )) || true
else
echo "FAIL: $name"
(( FAIL++ )) || true
fi
}
# Example test function
test_happy_path() {
local fx="$1"
mkdir -p "$fx/dist"
echo 'app.js' > "$fx/dist/index.js"
# Would normally run: kcov "$cov_out" "$SRC" --env=staging "$fx"
echo "[test] happy path executed in $fx"
}
run_test 'happy_path' test_happy_path
echo "Results: $PASS passed, $FAIL failed"
(( FAIL == 0 ))Tietotesti: vale-PATH-tekniikka
Testatkaa ymmärrystänne Bash-testifiktuureissa käytetystä vale-PATH-tekniikasta.
Kertaus: testifiktuurit, väliaikaiset ympäristöt ja kattavuus
Tässä oppitunnissa käsiteltiin luotettavan ja eristetyn Bash-testauksen koko työkalupakki:
- Väliaikaiset hakemistot —
mktemp -dyhdessä komennontrap ... EXITkanssa takaa automaattisen siivouksen riippumatta siitä, miten testi päättyy. - Testifiktuurin rakenne — funktioiden
setup_fixturejateardown_fixturepari luo ja poistaa minimaalisen hakemistopuun, joka vastaa todellisten skriptisyötteiden rakennetta. - Vale-PATH — sijoittakaa tynkäohjelmat hakemistoon
$FIXTURE/bin/ja lisätkää se$PATH-muuttujan alkuun siepataksenne kutsut ohjelmillecurl,aws,dockertai mille tahansa ulkoiselle työkalulle koskematta järjestelmän binääritiedostoihin. - Ympäristön rajaaminen — suorittakaa testattava skripti alikuoressa (
()taienv -i), jotta muuttuneet arvot eivät vuoda takaisin testiajuriin. - Väitteet — pienet apufunktiot (
assert_eq,assert_file_exists,assert_contains) tuottavat selkeän onnistumis- tai epäonnistumistulosteen sekä merkitykselliset virheilmoitukset. - kcov-kattavuus — ympäröi skriptin suorituksen ilman lähdekoodimuutoksia ja tuottaa HTML- ja JSON-raportit rivi- ja haarakattavuudesta.
- Yhdistäminen ja kynnysarvo — yhdistäkää useat kcov-ajot komennolla
--merge, jäsentäkää JSON ja epäonnistuttakaa CI, jos kattavuus laskee vähimmäisarvon alle. - Haara- ja rivikattavuus — kohdistakaa testaus aina haarakattavuuteen; pelkkä rivikattavuus voi ohittaa kokonaisia ehtopolkuja ja antaa väärän turvallisuuden tunteen.
Näillä tekniikoilla Bash-testinne ovat yhtä perusteellisia kuin minkä tahansa käännetyn kielen testit.
Opi Bash tekoälytuutorin avulla — ilmaiseksi
Kirjoita ja suorita oikeaa koodia selaimessa, saa välitöntä apua tekoälytuutorilta ympäri vuorokauden ja jatka siitä, mihin jäit, verkossa tai sovelluksessa.
- Kurssit
- 22
- Oppitunnit
- 88
Usein kysytyt kysymykset
Onko oppitunti ”Testiaineistot, väliaikaisympäristöt ja kattavuus” ilmainen?
Kyllä – oppitunnin ”Testiaineistot, väliaikaisympäristöt ja kattavuus” koko tekstin voi lukea täällä verkossa ilmaiseksi. Jos haluat harjoitella interaktiivisesti sisäänrakennetulla koodieditorilla ja ympäri vuorokauden käytettävissä olevan tekoälytuutorin avulla sekä avata koko Linux-komentorivin ja Bash-komentosarjojen hallinta-kurssin, päivitä CoddyKit PROhon. Linux-komentorivin ja Bash-komentosarjojen hallinta-kurssilla on yhteensä 4 oppituntia.
Mitä opin oppitunnilla ”Testiaineistot, väliaikaisympäristöt ja kattavuus”?
Rakenna eristettyjä testiaineistoja ja mittaa, mitä skriptin haaroja testisi todella suorittavat. Harjoittelet Linux-komentorivin ja Bash-komentosarjojen hallinta-aihetta koodilla, jonka suoritat suoraan selaimessa. Ympäri vuorokauden käytettävissä oleva tekoälytuutori vastaa kysymyksiisi oppitunnin aikana.
Tarvitsenko kokemusta aloittaakseni Linux-komentorivin ja Bash-komentosarjojen hallinta-opiskelun?
Aiempi kokemus ei ole tarpeen. CoddyKitin Linux-komentorivin ja Bash-komentosarjojen hallinta-oppimispolku sopii vasta-alkajista edistyneisiin, joten voit aloittaa tästä tai alusta ja edetä omaan tahtiisi. Tämä on oppitunti 3/4.
Kuinka kauan ”Testiaineistot, väliaikaisympäristöt ja kattavuus”-oppitunnin suorittaminen kestää?
Useimmat CoddyKitin oppitunnit kestävät noin 5–10 minuuttia. Jokainen oppitunti on lyhyt ja interaktiivinen, joten edistyt tasaisesti ja voit jatkaa siitä, mihin jäit – sekä verkossa että sovelluksessa.
Voinko kirjoittaa ja suorittaa koodia tällä Linux-komentorivin ja Bash-komentosarjojen hallinta-oppitunnilla?
Kyllä. Jokainen Linux-komentorivin ja Bash-komentosarjojen hallinta-oppitunti sisältää sisäänrakennetun koodieditorin, joten voit kirjoittaa ja suorittaa oikeaa koodia suoraan selaimessa ja saada välitöntä palautetta tekoälyltä – paikallista asennusta ei tarvita.
Kaikki tämän kurssin oppitunnit
- Funktioiden yksikkötestaus Bats-corella
- Komentojen mallintaminen ja ulkoisten työkalujen korvaaminen
- Testiaineistot, väliaikaisympäristöt ja kattavuus
- Shell-testien suorittaminen CI-putkissa