Hacker News Reader

Hacker News

Comment by aazaa | Hacker News Reader

Full thread

aazaa

If so, what replaced it?

What methods do teams use instead to ensure that:

1. software works as advertised

2. software can be refactored

If there's "no time" to write tests before code, it seems likely that there will also be "no time" to write them after.

If there are no tests, or test coverage is spotty, refactoring is going to be well-nigh impossible. If refactoring isn't done, the implementation is likely to be brittle. If implementation is brittle and no tests exist, few developers will want to touch the code for fear of it breaking. If no developers touch the code to keep it well-factored, the code will rot.

Now maybe this is the plan all along: code is written to decay and eventually disappear. But it doesn't sound like a recipe for long-term success.

So whenever these discussions about the use of TDD come up, I'm very curious about the specific ways teams address the two points I raised above.

View on HN

Believe it or not but good typed languages with a lot of compile time checks are probably one of the main reasons why TDD is not that big. Sure, these won't catch logic errors but most developers don't write that much heavy logic code anyway. And the senior developers are capable of writing mostly straight forward code that it’s easy to debug.

Type-checking, while helpful, can't always catch logical programming errors that result in user-facing bugs. We would have observed a marked increase in software quality with the advent of typed languages, but we haven't. Quality depends on more than just a typed language, whether that be unit tests, integration tests, etc.

I strongly disagree having years of experience in both Objective-C and Swift codebases / products

Disagree on general software quality? I've been an iOS user for about a decade now. Seen a couple of 'bad' (extremely buggy) apps here and there, but the quality seems relatively constant over time (possible sample bias).

Great product teams will build great products independently of Objective-C or Swift but you will need much less resources to deliver on the same quality using swift and modern frontend architectures.

I would also doubt the majority of apps in the Appstore today are using swift at least in the sense that I mean it. It’s not enough to use swift you actually need to know how to model your problem well using its type system and that takes experience. A lot of devs simply focus in solving narrow problems without giving much thought to how much more strict they can be with the language.

If you have a logic error what's to prevent you from making the same error when writing the test?

Manual testing and design patterns that isolate the effects of a change from the rest of the system.

I am going to manually test things anyways, so in practice, unit testing usually takes longer.

I am more likely to add robusts tests to parts of the code that are harder to test manually as it does save time in that instance.

Ironically, I find that well tested code gives me less incentive to refactor it. Refactoring is good for allowing future changes without breaking things. With good testing, I rely on tests to provide those guardrails instead of a clean code structure.

I guess it depends upon what kind of code you end up writing most. I tend to find lots of code I write has more complexity in the business logic sections than the UI itself - there are lots of corner cases with no impact on the UI.

I find automated testing (not necessarily TDD) adds a lot of value over manual testing in these scenarios. And the automated tests tend to pay off either at development time or after even a single change.

> 1. software works as advertised

Understanding (mutual) and communication seem to be the big & hard problems to tackle. Software reflects these issues clearly, even down to the detail. You can sometimes look at a particular chunk of code and understand how it got there from refining assumptions (etc.) or the lack thereof.

In terms of technical solutions I think one could just look at modern, more powerful concepts, like writing proofs and advanced typed systems in the static world, generative testing, controlling state via FP, gradual typing in the dynamic world etc. A whole host of bugs can be found w/o writing over-specific handcrafted tests.

> what replaced it?

In my experience, TDD has been "replaced" with laborious, time-consuming, low-coverage manual testing - that is, what it was originally meant to replace.

From another comment (thread moves fast):

The next big thing is ATDD - Acceptance Test Driven Development. This is implemented using frameworks like Cucumber[1], in which test scenarios are:

1. Described at the feature level

2. Described together with, and signed off by, the business stakeholders

3. Described in a structured format, which can be implemented in code ('given ... when ... then' format)

The advantages this gives are huge. It is essentially the business requirements described as test scenarios, which can be executed in an automated fashion, (co)authored and owned by the business.

[1] https://cucumber.io/

At my place, automated integration and end-to-end tests replaced TDD. There is an expanding number of unit tests, which usually aren't developed with TDD.

Reply on news.ycombinator.com