4 ms·
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
by aazaa 6y ago
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.
- jdmoreira 6y agoBelieve 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.
- JMTQp8lwXL 6y agoType-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.
- jdmoreira 6y agoI strongly disagree having years of experience in both Objective-C and Swift codebases / products
- JMTQp8lwXL 6y agoDisagree 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).
- jdmoreira 6y agoGreat 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.
- bufordtwain 6y agoIf you have a logic error what's to prevent you from making the same error when writing the test?
- commandlinefan 6y ago> 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.
- dgb23 6y ago> 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.
- mobjack 6y agoManual 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.
- bcrosby95 6y agoI 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.
- johnyzee 6y agoFrom 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/ https://cucumber.io/
- cuddlybacon 6y agoAt 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.