Hacker News Reader

Comment by pjmlp | Hacker News Reader

My fun test for TDD advocates is picking random GUI framework X and ask the presenter how to TDD a native GUI.

After all I am not supposed to show anything on the screen, send a shader to the GPU, or change any widget property without an existing test.

View on HN

AFAIU TDD, it's beneficial to have an automated test than can check what I'd check manually if I didn't have automated tests (since automated checking is quicker, and is consistent). One benefit of writing a test before fixing code is it avoids the problem of writing a test which passes but doesn't actually check the broken thing. ("You have to write the test before or else you're doing it wrong" seems overzealous or cargo-culting to me).

Of course, as with anything, "it depends" and so if you're confident that adding more tests would hinder your development more than benefit it, sure.

Some programming tasks are difficult to get the system setup for test input, or for checking test output. But it's not like you're not going to check whether the program works, and so it seems beneficial to make an automated test if you can.

I fully support automatic testing as far as possible.

Now TDD cargo culting of writing tests before working code, or even actual design of data structures just seems nonsense to me.

It only works for CLI demos of simple tools, or data processing pipelines.

Anything else seems convoluted, without a sound architecture design, and just impossible in some scenarios, e.g. GUI code, UI/UX.

Tests should be a mix of unit, module and integration tests, written after the architecture design, overall UI/UX design process, performance analysis if the chosen data structures are the best ones for the case at hand.

Given that there are plenty of test harnesses that allow for testing of GUIs, what about GUIs do you think proves impossible for the TDD process?

Large majority only work for browser based GUIs,

Then overall they are only able to validate the UI position or widget properties, which are like 25% of the overall UI/UX of a GUI and HIG compliance behaviors.

There are test frameworks for every tier of any application on any platform. People are getting it done.

Testing pixel presentation is a problem. Today, Automated macro tests can’t describe in a program how the UI should look before the UI is built. The UI is simply too dynamic and subject to the whims of fashion. But writing tests first for the UI and smoke testing that the UI elements are there and basically function is doable.

Most devs struggle keeping their micro testable code seprate from presentation code. TDD is a great way to incur this requirement. Otherwise it needs to be tested in a slow macro UI test. If you’re not familiar with the three tiers of the Test Automation pyramid, give Agile Thoughts episodes 1 through 4 a listen. It takes you through each stage of the pyramid and describes how macro (cutaneous and subcutaneous) and micro complement each other. https://agilenoir.biz/series/agile-thoughts/

> One benefit of writing a test before fixing code is it avoids the problem of writing a test which passes but doesn't actually check the broken thing.

In fairness, this isn't an ironclad guarantee. I have written tests that misled me. That was educational.

These days I do some quick mutations of the test and the code I wrote before moving on. My anecdata is that it catches errors in my tests maybe 5% of the time.

Nice idea to use defect injection to test the automated tests.

> One benefit of writing a test before fixing code is it avoids the problem of writing a test which passes but doesn't actually check the broken thing

Luckily code is version controlled so I can apply the test written afterwards to the old code with relative ease most of the time.

Reply on news.ycombinator.com