Test-driven development interleaves three small steps: write a test expressing the next required behavior and observe that it fails, implement enough behavior to make it pass, then improve the code's structure while keeping the tests passing. The retained tests become a regression suite. For example, before implementing a book deletion, test that deleting an existing contact removes it and returns true; later add the absent-name case. Each test guides a small implementation step rather than waiting for a finished component.[ref]
Test-driven development in the Agile Alliance glossary. What is TDD?: interleaving unit tests, implementation and refactoring in a short cycle
Compared with a traditional write-the-component-then-test workflow, tests guide the design before each increment is implemented. This does not imply that all non-TDD testing is postponed until a whole product is finished, or that TDD eliminates broader integration testing.
The test-first behavioral core is naturally black-box testing: expected outcomes come from the operation's contract. Later tests can use internal control flow or representation cases, becoming white-box testing. Thus a complete practice can use a mixture, with mainly contract-based black-box tests driving the next behavior. The classification depends on how test cases are chosen, not on whether the programmer personally knows the implementation. Passing a finite suite is not a proof of universal correctness.
In the Observer pattern, a subject maintains subscriptions through a common observation interface. Interested observers register and unregister; when a relevant state change occurs, the subject sends a notification, and each observer runs its own reaction. Notifications can carry the new information directly or prompt the observer to query the subject's coherent updated state.
This fits an event-driven programming interface in which one model can have several independently changing views: a displayed conversion, a chart or a status indicator can react to the same model change. It avoids hard-coding calls to every concrete view inside the subject, which would couple domain logic to presentation details and require editing the subject whenever another view is added. The subject depends on the observer interface rather than every concrete observer class.
The design still needs subscription cleanup and an update policy. Mutual notifications can create a feedback loop or a reentrant event handler, while an observer that reacts halfway through a state change can see inconsistent data. Publishing only coherent changes and controlling derived display updates address those problems; the pattern alone does not automatically solve them.
In Scala Swing, a
Publisher is the observable subject and a Reactor supplies an observer's reactions. A reactor calls listenTo(pounds, euros, rate) to subscribe to the relevant publishing components. It adds a partial function from events to actions with reactions += { case ... => ... }; unmatched event types need no action. When a publisher calls publish(e), subscribed reactions that handle that event are notified. Calling deafTo removes subscriptions that are no longer wanted.[ref]Scala Swing event-system documentation. README, About scala-swing: Publisher/Reactor, listenTo and reactions; archived Reactor API: deafTo
The publisher does not need to know the concrete frame or its currency-conversion code. A
TextField supplies the relevant editing events, and the frame's reaction distinguishes the source field using EditDone(source). Both registration and a matching reaction are needed: installing a case handler without subscribing does not establish the notification path. The observer logic should update the conversion model once and then refresh the other fields from that coherent state.Let the committed model be amounts and an exchange rate , with invariant . Editing pounds keeps the rate and computes euros; editing euros keeps the rate and computes pounds; editing the rate keeps pounds and computes euros. A usable rate must be strictly positive, and every accepted floating-point number and derived result must be finite. Negative amounts are allowed. Rejecting invalid text preserves the last committed model.
Insert the following members inside the supplied The invariant is interpreted with the usual floating-point rounding in multiplication and division. All candidate values are calculated before committing any of them, so invalid text, zero/negative rates, NaN, infinity and floating-point overflow leave the old model intact. The committed
MainFrame, after the three fields have been initialized. Its existing layout can remain as written:private var p = 10.0
private var e = 11.5
private var r = 1.15
private var refreshing = false
private def finite(x: Double): Boolean = !x.isNaN && !x.isInfinity
private def showModel(): Unit = {
refreshing = true
try {
pounds.text = java.lang.String.format(java.util.Locale.ROOT, "%.2f", Double.box(p))
euros.text = java.lang.String.format(java.util.Locale.ROOT, "%.2f", Double.box(e))
rate.text = r.toString
} finally {
refreshing = false
}
}
private def edit(source: TextField): Unit = {
try {
val v = source.text.trim.toDouble
if (finite(v)) {
var nextP = p
var nextE = e
var nextR = r
if (source eq pounds) {
nextP = v
nextE = v * r
} else if (source eq euros) {
nextE = v
nextP = v / r
} else if (source eq rate) {
nextR = v
nextE = p * v
}
if (nextR > 0.0 && finite(nextP) && finite(nextE) && finite(nextR)) {
p = nextP
e = nextE
r = nextR
}
}
} catch {
case _: NumberFormatException => ()
}
showModel()
}
listenTo(pounds, euros, rate)
reactions += {
case EditDone(source) if !refreshing => edit(source)
}r remains positive, so euro-to-pound division is defined. Using a fixed formatting locale keeps the decimal separator compatible with toDouble. The displayed amounts are rounded to two decimal places, while the model retains their full available precision. The rate is not forcibly rounded to two places, which could otherwise turn a valid small positive rate into displayed zero.The
refreshing guard prevents synchronous derived-field notifications from recursively committing another edit. EditDone is an edit-completion event, not a request to react to every partial keystroke; pressing the field's completion action is enough to trigger the conversion. If a particular UI additionally needs live updates, it can subscribe to the appropriate text-change events with the same validation and authoritative-source policy. The supplied API and archived Scala Swing documentation suffice for the requested completion-event implementation; no unidentified practical library is required.[ref]Scala Swing event-system documentation. Publisher/Reactor subscription design; archived Swing event API: EditDone carries its source TextField
Articles by others on the same topic
There are currently no matching articles.