4 ms·

> However, you really do need some automated testing. How would you distinguish automated testing from TDD? > If part of your burnout here is that you are jus

by porker 11y ago

> However, you really do need some automated testing. How would you distinguish automated testing from TDD? > If part of your burnout here is that you are just [expletive] tired of making changes in one bit of the code just for it to create 6 more bugs in the rest of it, automated testing is the core solution to that. I do so much legacy maintenance/development, and yes this would make my life a lot easier. Not for my edits creating bugs (ok, sometimes ;)) but for platform runtimes changing and ensuring nothing breaks (PHP 5.3 => PHP 5.6 for example). A new job... yes it's easy to get pigeonholed into a field. The work I've loved the last few years has been tasks like "develop a custom plotting algorithm so overlapping points aren't hidden (and labels don't overlap)". This has been the work that's fallen in my lap; I haven't found a source for such interesting projects (the ones that push me into areas I don't know). Though that exciting plotting algorithm also required an entire CRUD admin interface which nearly killed me (from lack of motivation). I need to outsource those bits... Alternatively there is the "productized consulting" route, but until I have a product idea to productize I'll stick with what I do well: problem solving :)

jerf 11y ago
"How would you distinguish automated testing from TDD?" I would consider the distinguishing characteristic of TDD is that you write the tests first. There's varying levels of strictness there from little more than that restriction, to varying levels of dogmatism on writing code that only makes the test pass. I consider this a great way for a new programmer to learn how to really design code. In fact it's one of the only ways I know to practically teach design. However, once you have experience, the really dogmatic TDD involves writing simple tests, then writing code to pass the tests that you, in your experience, know will be driving yourself into a local optima that will not be able to carry the design. But when you lack that experience and knowledge, well, it's a great way to get it while learning a good dose of YAGNI. (Which I do not consider an absolute, but is something everybody needs to exercise.) In contrast to "TDD" which I consider optional, automated testing has provided so much value to me in so many diverse parts of the stack that I consider it a no-brainer; it is a positive value to any project. The exceptions are things where the code is so not-amenable to testing that it is essentially untestable. Note this only applies to code written by someone else; if you wrote it, fix it to be testable. In particular, GUIs are a royal pain here. It is my belief this is not a fundamental attribute of GUIs, but a GUI not written to be testable is nigh untestable. (And if you find it isn't bringing you value, you're probably doing it wrong. There are wrong ways to do it. Test code is real code; apply all the arts of refactoring, DRY, and learning from experience as you do to "real" code.)
- porker 11y ago
  Thank you, that makes sense and why TDD is so worthwhile for me to start with. For external services (I rarely write code that doesn't rely on at least one SOAP endpoint) is there any alternative to mocking the service and the response data? And then should your tests also verify that the remote service works according to its contract? As it would affect data in the live system, I cannot think of a way to safely do it, but 3rd party systems have 'changed' their behaviours before now, and that's a horrible bug to track down.
  - jerf 11y ago
    "For external services (I rarely write code that doesn't rely on at least one SOAP endpoint) is there any alternative to mocking the service and the response data?" In practice, no. Though I prefer some variant to dependency injection to "mocking". I consider the testability a first-class concern and code accordingly. Exactly how this manifests varies suprisingly widely between various languages. You don't mention your language, so I don't have specifics. "And then should your tests also verify that the remote service works according to its contract?" Yes, but rather than thinking of that as "automated testing", you're better off thinking of that as "service monitoring" that happens to look like automated testing. Consider something like: http://n8v.enteuxis.org/2011/06/integrating-nagios-with-test-driven-development/ http://n8v.enteuxis.org/2011/06/integrating-nagios-with-test...

by porker 11y ago

jerf 11y ago

"How would you distinguish automated testing from TDD?" I would consider the distinguishing characteristic of TDD is that you write the tests first. There's varying levels of strictness there from little more than that restriction, to varying levels of dogmatism on writing code that only makes the test pass. I consider this a great way for a new programmer to learn how to really design code. In fact it's one of the only ways I know to practically teach design. However, once you have experience, the really dogmatic TDD involves writing simple tests, then writing code to pass the tests that you, in your experience, know will be driving yourself into a local optima that will not be able to carry the design. But when you lack that experience and knowledge, well, it's a great way to get it while learning a good dose of YAGNI. (Which I do not consider an absolute, but is something everybody needs to exercise.) In contrast to "TDD" which I consider optional, automated testing has provided so much value to me in so many diverse parts of the stack that I consider it a no-brainer; it is a positive value to any project. The exceptions are things where the code is so not-amenable to testing that it is essentially untestable. Note this only applies to code written by someone else; if you wrote it, fix it to be testable. In particular, GUIs are a royal pain here. It is my belief this is not a fundamental attribute of GUIs, but a GUI not written to be testable is nigh untestable. (And if you find it isn't bringing you value, you're probably doing it wrong. There are wrong ways to do it. Test code is real code; apply all the arts of refactoring, DRY, and learning from experience as you do to "real" code.)

porker 11y ago
Thank you, that makes sense and why TDD is so worthwhile for me to start with. For external services (I rarely write code that doesn't rely on at least one SOAP endpoint) is there any alternative to mocking the service and the response data? And then should your tests also verify that the remote service works according to its contract? As it would affect data in the live system, I cannot think of a way to safely do it, but 3rd party systems have 'changed' their behaviours before now, and that's a horrible bug to track down.
- jerf 11y ago
  "For external services (I rarely write code that doesn't rely on at least one SOAP endpoint) is there any alternative to mocking the service and the response data?" In practice, no. Though I prefer some variant to dependency injection to "mocking". I consider the testability a first-class concern and code accordingly. Exactly how this manifests varies suprisingly widely between various languages. You don't mention your language, so I don't have specifics. "And then should your tests also verify that the remote service works according to its contract?" Yes, but rather than thinking of that as "automated testing", you're better off thinking of that as "service monitoring" that happens to look like automated testing. Consider something like: http://n8v.enteuxis.org/2011/06/integrating-nagios-with-test-driven-development/ http://n8v.enteuxis.org/2011/06/integrating-nagios-with-test...