Disclaimer: I am an assclown who makes cobbles shit together and doesn't have a strong/real foundational understanding in the shit I deal with.

So does anybody actually write their tests before they write their code? I see the term TDD (test driven development) bandied around everywhere.

I don't know what the fuck I'm doing or what the solution will be, nor am I confident in it until I've manually tested it seems to be working.

Then I usually write the automated tests if they are easy to do so.

i.e. I won't know what/how to test the thing.....until I make the damn thing

Is this a case of 'git gud' and have the problem "presolved" in your head, before you work on it such that you can already write tests first?

Or is this a case of "aGilE", where everybody says they're agile, maybe does a little bit of scrum (just the pieces they like/find useful, not the entire thing in a dogmatic/religious way), and possibly has never heard of the manifesto https://agilemanifesto.org/

  • 4
    I was taught religious TDD with triple-A + data-driven tests and it gave me a drive to write all the classes/functions I write testable and easily maintainable.

    I like the shu-ha-ri idea. First you MUST try it religiously, follow every rule (shu). After that, you can start tweaking the rules, see what works better and what doesn't (ha). Afterwards you can make your own rules and develop your own way of working (ri). Then you can master an art.

    Look up 'We tried baseball, it didn't work'.

    Anyway, I think it gives you a good sense/feeling of how to write good maintainable code since you're anticipating your tests.
  • 3
    TDD is cumbersome.

    Most people misunderstand one core concept of TDD: small units of code.

    You write a test _after_ you have an _finished_ design which is breakable in small units which can be coded easily.

    This is missing in most descriptions.

    Otherwise - yes. Fail hard since you start in Nil and end with Chaos.
  • 1
    Hello, assclown

    I (and the companies I worked at) don't do TDD. simple unit testing and a thorough integration and regression testing after or during the development have been very helpful so far
  • 4
    I can't do test-first development. How do I know what to test, before I've tried to write it?

    No, for me it's: implement idea A; write tests; discover A is dumb; implement idea A'; rewrite tests; etc. until version A'''''' isn't an embarrassment and a sin against software.
  • 2

    I'm gonna be now the nitpicky bastard arsehole of instructor....

    This is not the problem of test first.

    You skipped design and walk the path of implementation _only_.

    That's dangerous - and you'll loose time.
  • 3
    Having trouble with code quality? Write a lot of tests. And I mean a *lot*. Test every file in isolation. Mock as many imports as possible. When you're done, your code will still be bad, but now your tests will make sure it's impossible to improve anything in any meaningful way.
  • 1
    We're all ass clowns to some extent ;)
  • 3
    The real advantage I find with TDD is that in doing things that way, it forces you to *design* your code in a way that can be sanely unit tested.

    This is the big piece of the testing pie that almost all training misses IMHO, but also one of the most important. If you don't design your code and split it up properly into sane, cohesive units, then you'll find testing an absolute nightmare. Most likely you'll find yourself just trying to hit an arbitrary test coverage level by using overly complex and fragile integration tests, if you bother at all.

    Yes, when you start out you'll end up rewriting and refactoring more code than you would have otherwise with the above approach - but I believe that'll make you a better Dev in the long run.
  • 0
    You say you don't really know what you are doing or what your goal is when you start writing a program. But that's exactly the path TDD helps you avoid going down.

    With TDD you cannot just dive in without having thought about what you are going to build.

    There are totally valid reasons not to do it, like with all methods it has its pros and cons. But more often than not, diving in to code something without thinking about what you want that something to look like and do, is going to lead to lots of issues down the road.
  • 0
    @IntrusionCM The thing is, implementation informs design. Putting my more serious hat on: at least in the application domains I find myself in, it's a rare day indeed when I can follow a top-down specify->design->turn specification into tests->implement work flow.

    If the situation is at all novel, chances are that you don't actually know what the best (or at least, sufficiently good) design is until you get your hands dirty.
  • 2
    The problem with TDD is that you can plan out your implementation, break everything down into testable bits, iterate until your tests pass and then realize you did it wrong after you actually try it out for real, and now you have to rewrite 2 things instead of just 1.
  • 2
    I have used TDD sometimes when I have a good idea of the interface I need.

    But if I have no idea of what interfaces I need or how the overall design of the code should be TDD does not work very well.

    In my case it was a script runner where the script language was already specified, thereby giving me a clear goal to achieve :)
  • 1
    @uyouthe Do you really think converting to womanhood would stop me from checking out that aSsSsss?
  • 1
    @rutee07 I have onlyfans 💖
  • 0
    I don't even know how to properly write a unit test. Would like to learn but I have margins to correct and designers to please. Nobody here cares about anything long term.
Add Comment