5 ms·

Testing. I have never done TDD; I put it off in the beginning as an extra cost to clients (or time lost for me), and then when it became trendy I (as ever) disl

• jerf 11y ago
  I think TDD is a great exercise to do a couple of times, and a great way for a new developer to grow some good habits very quickly. I'm much, much less convinced of its utility for people with experience. However, you really do need some automated testing. One of the reasons I love automated testing is that it permits me to make (nearly) monotonic forward progress on my tasks. 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 used to get that type of burnout... I don't anymore, except when I'm stuck crawling around somebody else's code base where I can't add testing for some reason. Also, rather than posting another comment, rather than a new "field" you may just need a new job. It isn't all CRUD coding. Mind you, there isn't really much out there that is fascinating cutting-edge research every day, either; even that involves a lot of grunt work. But it isn't all CRUD work out there, either.
  • 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...
• nerdy 11y ago
  First, that alleged "extra cost" is the #1 myth. It might be true of test-last (code then test, anti-TDD; whatever it's called)-- I am not sure because I've never tested that way and that process is transparently ineffective if you take a very structured approach to the process (more later). I've been at a place where I also believed the same thing but since then I've built larger and larger systems and felt these pains. While TDD will slow you down initially as you learn, once you're comfortable with your testing framework, you'll notice you don't really go slower because you have near zero debug time, feel absolutely empowered to refactor and clean code, clarify intentions and just generally make everything crystal clear without breaking anything. You'll also notice that in most cases, as projects grow large and cumbersome, you keep that same steady methodical pace Second, TDD is not E2E testing. There are tools for E2E but when we're talking about refactoring or structural organization it isn't so much a matter of UIs as it is a matter of what happens within the logical decisions of the system, which hopefully is not contained within the UI for non-UI logic. The description of your problem does not sound like you have an issue with the website's frontend but with the complexity of its brains behind the scene. So you'll want some tests to cover the application code units individually (unit tests), and something which makes sure you can glue all of those pieces together and they still work as expected (integration tests). An integration test is not end-to-end, it's simply multiple components. Each of those components should already have passing tests, so you should have very high confidence that they work in isolation. The integration test simply makes sure they're connected the right way. I prefer as few integration tests as possible (but at least 1). If you have lots of integration tests you're probably performing at least some testing which should be covered by unit tests within those integration tests. Integration tests should just make sure the components are compatible and connected, not really test their internal behaviors. I personally do the highest level of finalized testing (V&V) manually because I've proven the components work and are wired correctly, so the UI is usually just a dumb wrapper dumping out HTML. I open a browser and click around, make sure it works, think about how I can break it, beat it up for a few minutes and appreciate my work. You could automate this part of the process but I haven't found sufficient reason to (yet). TDD is simply writing an assertion and then satisfying it with code. At the end, you've independently computed and verified that some tiny granule of code has some certain behavior. When I started I'd think to myself "ok, I'm going to write the sorting code" and then I'd run off writing tests to make sure some simple structure was sorted after being passed through the method. That's way too fast. The best way I've heard the proper approach described is when Bob Martin says "test the most degenerate case first". So my sorting would start off with sorting null. What should happen if that unit gets null instead of the expected array? What does it return? Does it throw an Exception? Refactor time. Why does the code suck? How would it be easier to understand? Any methods too long? Any repetition? Don't add tests, don't change behavior. Only change the way the result is reached. Test subsequent cases like null/false/zero/undefined. Refactor after each, if appropriate. Don't skip refactoring! You don't always have to do it but you should consider whether or not it is currently appropriate. After those cases you can test the simplest things; an empty array. It should probably return an empty array. Then refactor. Then a single-element array, refactor, then two... then three, then the three in various orders. At a certain point you can't write a test that fails. You're done with this unit of code. Everything provably works. I realize all of this seems like an overengineering process that's too low-level to be remotely sane. Seriously, I understand why you might think that. The thing is, all code is written one line at a time. Every second spent on the tests is paid for by the absence of debugging, dumping variables to screen, viewing source, etc. I'd argue that time spent debugging is time least effectively spent, particularly when in vein. BTW money isn't my primary motivator either, I just enjoy programming. Make the best of it; do what you enjoy and get paid for doing it but don't look at the money as a carrot. If you can't stay motivated then maybe it isn't a matter of career but a matter of the project or industry?