Förvirrade tester döljer verkliga problem 
 
 TL;DR: Du lägger flera påståenden i ett test, vilket gör misslyckanden svåra att analysera. TL;DR: Du lägger flera påståenden i ett test, vilket gör misslyckanden svåra att analysera. Problem 
 
 
 
 
 
 
 
 
 Läsbarhet Bräckliga tester Långsamt test Debugging smärta Kopplad logik Underhålls mardröm Tvetydiga misslyckanden Generiska påståenden Lösningar 
 
 
 
 
 
 Följ One-Assert-Per-Test-regeln Extrakt av assertmetoder Använd beskrivande testnamn Grupprelaterade kontroller Refactor test logik i mindre bitar Återhämtning ️ https://hackernoon.com/improving-the-code-one-line-at-a-time?embedable=true https://hackernoon.com/refactoring-013-eliminating-repeated-code-with-dry-principles?embedable=true https://maximilianocontieri.com/refactoring-010-extract-method-object?embedable=true https://maximilianocontieri.com/refactoring-011-replace-comments-with-tests?embedable=true sammanhanget När du kram flera påståenden i ett enda test, misslyckanden blir tvetydiga. Du vet inte vilken del av koden som orsakade felet. Föreställ dig ett test med fem påståenden misslyckas på den andra - du ser aldrig om påståenden 3, 4 och 5 skulle ha passerat eller misslyckats, gömmer ytterligare brister. Testerna ska vara exakta, lätta att förstå och fokuserade. Varje test bör validera ett enda beteende och tydligt kommunicera dess syfte. En enda testfunktion bör testa en enda verklig sak/koncept. Du bör inte skriva långa funktioner som testar orelaterat beteende sekventiellt. Detta försvårar vanligtvis den svåra och och setup. Kopplade Sample kod Felaktigt 🙂 def test_car_performance():
    car = Formula1Car("Red Bull")
    car.set_speed(320)
    assert car.speed == 320
    car.accelerate(10)
    assert car.speed == 330
    car.brake(50)
    assert car.speed == 280
    car.change_tire("soft")
    assert car.tire == "soft"
 Rätt 🙂 def test_set_speed():
    car = Formula1Car("Red Bull")
    car.set_speed(320)
    assert car.speed == 320, (
        f"Expected speed to be 320 km/h, "
        f"but got {car.speed} km/h"
    )

def test_accelerate():
    car = Formula1Car("Red Bull")
    car.set_speed(320)
    car.accelerate(10)
    assert car.speed == 330, (
        f"Expected speed to be 330 km/h "
        f"after accelerating by 10, "
        f"but got {car.speed} km/h"
    )

def test_brake():
    car = Formula1Car("Red Bull")
    car.set_speed(330)
    car.brake(50)
    assert car.speed == 280, (
        f"Expected speed to be 280 km/h "
        f"after braking by 50, "
        f"but got {car.speed} km/h"
    )

def test_change_tire():
    car = Formula1Car("Red Bull")
    car.change_tire("soft")
    assert car.tire == "soft", (
        f"Expected tire type to be 'soft', "
        f"but got '{car.tire}'"
    )
 Upptäckten 
 
 [x] Automatiskt Kontrollera för tester med mer än ett påstående. Leta efter tester som misslyckas av flera skäl eller täcker flera orelaterade åtgärder. De flesta linters och testramar kan flagga flera påståenden. Ställ in en regel för att varna när tester överskrider en eller två påståenden. Undantag Du kan gruppera flera påståenden endast när de validerar samma logiska beteende eller utdata för en ren funktion. Dagar ️ 
 
 Testning Nivå 
 
 [x] Medelstora Varför det är så viktigt ️ Du behöver en mellan Enheter och dina tester. Bijection kartan Om ett test kontrollerar flera beteenden bryter misslyckanden denna kartläggning. När ett test misslyckas bör du omedelbart veta exakt vilket beteende som bryts utan att läsa testkoden. Den här generationen AI-generatorer producerar ofta tester med flera påståenden, försöker täcka allt i ett enda skott. Detta beror på att AI-verktyg optimerar för kodtäckning snarare än test klarhet, behandla tester som checklistor snarare än beteende specifikationer. Detektion AI kan refactor test för att hålla ett påstående per test. Prova dem! Kom ihåg: AI-assistenter gör många misstag 
 
 Föreslagna prompt: Refactor den här testfilen för att innehålla en påstående per testmetod. Föreslagna prompt: Refactor den här testfilen för att innehålla en påstående per testmetod. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Without Proper Instructions 
 With Specific Instructions 
 
 
 
 ChatGPT 
 ChatGPT 
 
 
 
 Claude 
 Claude 
 
 
 
 Perplexity 
 Perplexity 
 
 
 
 Copilot 
 Copilot 
 
 
 
 You 
 You 
 
 
 
 Gemini 
 Gemini 
 
 
 
 DeepSeek 
 DeepSeek 
 
 
 
 Meta AI 
 Meta AI 
 
 
 
 Grok 
 Grok 
 
 
 
 Qwen 
 Qwen Chattar Chattar Claude är Claude är förvirring förvirring Barnpilot Barnpilot du du Tvillingar Tvillingar djupt sökande djupt sökande Målet för AI Målet för AI Grekiska Grekiska Kvinna Kvinna Slutsats Testerna ska vara fokuserade och exakta. Du måste snabbt förstå vilket avtal som bryts. Undvik flera påståenden per test för att göra misslyckanden tydliga, felsökning snabbare och din testpaket underhållbar. Relationer https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xi-sit35t1 https://hackernoon.com/code-smell-03-functions-are-too-long-heres-how-to-fix-that https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-x-i7r34uj https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxi Mer information https://hackernoon.com/coupling-the-one-and-only-software-designing-problem-9z5a321h Disclaimer Doften är min . åsikt Krediter Foto från är Huvudstad Venugopal Unsplash 
 
 Testning handlar inte om att hitta buggar, det handlar om att förstå dem Testning handlar inte om att hitta buggar, det handlar om att förstå dem av Brian Marick https://hackernoon.com/400-thought-provoking-software-engineering-quotes?embedable=true Denna artikel är en del av CodeSmell-serien. https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-i-xqz3evd?embedable=true

Winner of Noonies 2020 for the award Hacker Noon Contributor of the Year - REFACTORING.

2020 - Hacker Noon Contributor of the Year in REFACTORING

2022 - HackerNoon Contributor of the Year - Clean Code

2022 - HackerNoon Contributor of the Year - Debugging

2022 - HackerNoon Contributor of the Year - Github

2022 - HackerNoon Contributor of the Year - Machine Learning

2022 - HackerNoon Contributor of the Year - Quality Assurance

2022 - HackerNoon Contributor of the Year - Refactoring

2022 - HackerNoon Contributor of the Year - Software Architecture

2022 - the Greatest Storyteller

Buy My Book

Share your ideas with me!

Read My Stories

Buy Me a Coffee

Software Engineer and Book Author

Det här ljudet är producerat på berättelsens originalspråk!

För länge; Att läsa

Code Smell 312 - Du lägger flera påståenden i ett test, vilket gör misslyckanden svåra att analysera

Code Smell 312 - Du lägger flera påståenden i ett test, vilket gör misslyckanden svåra att analysera

About Author

KOMMENTARER

HÄNG TAGGAR

DENNA ARTIKEL PRESENTERAS I

Related Stories

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps