https://datatweets.com/courses/software-engineering/writing-quality-tested-code/Recent content in Writing Quality, Tested Code on DATATWEETSHugoenCopyright (c) 2025 DatatweetsSun, 05 Jul 2026 09:00:00 +0200https://datatweets.com/courses/software-engineering/writing-quality-tested-code/lesson-1-clean-code-and-best-practices/Sun, 05 Jul 2026 09:00:00 +0200https://datatweets.com/courses/software-engineering/writing-quality-tested-code/lesson-1-clean-code-and-best-practices/This lesson opens Module 3 by rewriting a tangled Ledgerly function called calc(x, tmp, flag, d) into five small, well-named functions. You will learn how to name things so they need no comment, how to size a function so it does one job, when a comment signals a naming problem instead of adding value, why consistent formatting matters, and how to fail fast with specific exceptions instead of silent failures.https://datatweets.com/courses/software-engineering/writing-quality-tested-code/lesson-2-software-testing-fundamentals/Sun, 05 Jul 2026 09:00:00 +0200https://datatweets.com/courses/software-engineering/writing-quality-tested-code/lesson-2-software-testing-fundamentals/This lesson takes the clean pricing functions from Lesson 1 and puts them under test. You will write pytest unit tests for calculate_invoice_total and its helpers, build a fake PaymentGateway so tests never touch a real payment network, and measure why one broad end-to-end test runs far slower than a full suite of unit tests. It closes with what test coverage actually measures, and a real example of a bug that 100% coverage does not catch.https://datatweets.com/courses/software-engineering/writing-quality-tested-code/lesson-3-behaviour-driven-development/Sun, 05 Jul 2026 09:00:00 +0200https://datatweets.com/courses/software-engineering/writing-quality-tested-code/lesson-3-behaviour-driven-development/This lesson introduces behaviour-driven development (BDD), where business people, developers, and testers describe a feature’s behavior in one shared, plain-language format before any code exists. You follow Ledgerly’s three-person team through a three-amigos session for a new discount-code feature, then turn that conversation into a Given-When-Then scenario. A working Python example then runs that scenario as a real executable specification, with output captured directly from the interpreter. By the end, you can explain how BDD differs from plain unit testing and why BDD scenarios double as living documentation.https://datatweets.com/courses/software-engineering/writing-quality-tested-code/lesson-4-the-gherkin-language/Sun, 05 Jul 2026 09:00:00 +0200https://datatweets.com/courses/software-engineering/writing-quality-tested-code/lesson-4-the-gherkin-language/This lesson teaches the full syntax of Gherkin, the plain-text language behind the BDD scenarios Lesson 3 introduced. You write real feature files for Ledgerly, covering the Given, When, Then, And, and But step keywords, a Background block that removes setup repeated across every scenario, and a Scenario Outline with an Examples table that runs one scenario against several discount codes. You also learn how tags like @billing and @smoke let a team filter which scenarios a test run executes.https://datatweets.com/courses/software-engineering/writing-quality-tested-code/lesson-5-guided-project-testing-ledgerly-with-bdd/Sun, 05 Jul 2026 09:00:00 +0200https://datatweets.com/courses/software-engineering/writing-quality-tested-code/lesson-5-guided-project-testing-ledgerly-with-bdd/In this guided project you build one real Ledgerly feature, pausing a subscription’s billing for up to two months with automatic resumption, and prove it works from three angles. You write a small, single-purpose implementation, back it with real unittest tests that run and pass, and specify the same behavior again in a Gherkin feature file with a Background, a Scenario, and a Scenario Outline covering multiple pause lengths. A closing reflection makes explicit what the Gherkin layer adds that the unit tests alone do not.