Create accountLogin

Recent searches

No recent searches

Search options

Only available when logged in.
mathstodon.xyz is one of the many independent Mastodon servers you can use to participate in the fediverse.
A Mastodon instance for maths people. We have LaTeX rendering in the web interface!

Administered by:

Server stats:

2.7K
active users

mathstodon.xyz: AboutStatusProfiles directoryPrivacy policy

Mastodon: AboutGet the appKeyboard shortcutsView source codev4.3.7

#tdd

3 posts3 participants0 posts today
Public
Jan Van Ryswyck

Test-Driven Development can be considered as reducing your WIP (Work-In-Progress) at a microlevel. By focusing on writing just enough code to make a failing test pass, refactoring what you added and push to source control, we minimise the amount of unexecuted code (= WIP). Limiting WIP is essential for fast software delivery.

#tdd#unittests#softwaredesign
Public
Ted M. Young

_Event-Sourcing Live Coding_

I've been live coding an example #EventSourcing app in #Java (via #TDD) w/o an ES library.

This week I'll continue to code the "Time-Traveling Event Viewer" to view the state at any point in time.

Join me Mon-Thur 18:00 UTC jitterted.stream

TwitchJitterTed - TwitchTed M. Young is a Coding Coach, Technical Trainer, Programming Presenter, and amateur guitar player. Focusing on Java, Spring, TDD, OOP, Hexagonal Architecture, and the Science of Learning.
Replied in thread
Public
das-g

What you're describing in this thread, @GeePawHill, is micro-testing (famously a clear-box technique, so what you say about it is uncontested), not «canon» TDD (tidyfirst.substack.com/p/canon) as envisioned by those that coined the term TDD.

In #TDD—although also a #clearBoxTechnique—when you write the next test, the box will usually not yet contain the logic to make it pass, so you can't base the test on the implementation of that logic. You run the new test and see it fail to prove that assumption.

Software Design: Tidy First? · Canon TDDBy Kent Beck
Replied in thread
Public
Peter Sommerlad

@GeePawHill

One danger of a too transparent box used for TDD is that tests get too coupled to a specific implementation and thus hinder refactoring and evolution. ie, taking the soft out of software.

Sure you are aware of that, but novices easily fall into that trap, when they not have learned enough about refactoring towards simpler code.

#TDD#Refactoring
Public *
amen zwa, esq.

I was an undergrad, when I backed into . This was the age when assembly was the JavaScript of the day and structured programming was the state-of-the-fart. So, it was a jolt, when I first encountered Test-Driven Development in the early 2000s, thanks to the luminaries like Kent Beck, et al. Brilliant stuff!

But, at the risk of being drawn and quartered, I do say that TDD is a bit of a misnomer and an overstatement. Honestly, answer this: do EEs really create the hardware test suits first, before conducting analysis and design, and do CSs really create the software test suits first, before performing analysis and design?

No, we do not! We analyse the problem, we study the requirements, we search for inspiration in the literature, we sip our tea or coffee, we select a candidate solution, we create a plausible design, we implement a prototype, then we test—yes, THEN, WE TEST—if our wild imaginations have any basis in reality at all.

So, I prefer a more down-to-earth description of TDD, which says, "test early, test often, test as much as practicable", not "test first, because".

Public *
QUnit

Ever wondered how beforeEach works in unit test frameworks? Check out our new lifecycle diagram!

qunitjs.com/lifecycle/

People generally guess right when it comes to ordering, so why a diagram?

We want to show that the order is guaranteed, and showcase what's possible when you depend on it.

Thanks to FND, Jan, and NullVoxPopuli for improving and promoting this work! H/T @FND @simulo @nullvoxpopuli

Imagine a test with global hooks, and a Parent and Child module that use hooks also. The execution order is: 1. Parent module runs the before hook. 2. Every test in the Parent module inherits context from the before hook, and repeats as follows: call global beforeEach, parent beforeEach, the actual test, parent afterEach, and lastly the global afterEach. 3. The Child module inherits context from the Parent before hook, and then runs its own before hook. 4. Every test in the Child module inherits context from this before hook, and repeats as follows: call global beforeEach, parent beforeEach, child beforeEach, the actual test, child afterEach, parent afterEach, and lastly the global afterEach.
#qunit#WriteTheDocs#TechnicalWriting
Public
Boyd Stephen Smith Jr.

> Test-driven development (TDD) is a way of writing code that involves writing an automated unit-level test case that fails, then writing just enough code to make the test pass

(Wikipedia)

So, #TDD fans, how do you write your first test(s)? Like, how do you deal with the fact that none of the implementation you will be writing has any names yet? Do you violate this principle some and stub out implementation objects to give them names? Do you write tests that "fail" due to missing names? In a statically-typed language, how do you accomplish the later -- consider failure to compile a "test failure"?

I'm generally a fan of TDD, but I never _actually_ start from the tests. They are always something that comes later but, potentially, become a driver in the future.

SearchLive feeds
About