27
gdb123
14d

testers coding...

Comments
  • 8
    Yep. Your organization will happily create a whole new siamese twin set of code. Equally as big as the actual application code. Chock full of cases that will never exist in the real world. More tightly coupled to the application code than a couple of horny 17 year olds. This "test" code will make future changes cost multiples what they did before. And yet, management will equate the existence of that "test" code" with quality. When it turns out the software is still crap, they will blame the developers for not writing good enough tests and demand 110% test coverage for the next release.
  • 2
    Also Unit Testing
  • 1
    @monkeyboy ah shit. Someone that dislikes tdd as well
  • 0
  • 0
    @monkeyboy Well, one thing is tdd the other is writing sensible tests. I can't truly trust my code if I don't have unit tests that covers the most reasonable scenarios. When something breaks I know where to start looking :)

    It's not always like that, when it's not I just write another test that covers this failure :)
  • 2
    @7Raiden You have hit upon the most important facet of unit or automation testing when you say you know where to look when something goes wrong. Testing does not provide quality. It provides a level of change notification. That's all. The code can be awesome or crap regardless of test coverage. So, as with any effort, the question asked about testing shouldn't be about test coverage, it should be about whether it's worth the cost.
  • 0
    Androidx testing
  • 0
    @monkeyboy yeh, writing tests suck,

    but it depends on what applications you write. when its about long (years, decades) living applications, you are not right. its a good thing for a company, its a good thing for costs.

    if you have the feeling that tests are a waste of money/time then, imho, you
    - dont write sensible tests or
    - develop applications where its not about quality (short living, low risk)

    AND you must always keep in mind, that the meme is wrong: you dont write the test to confirm that what you just coded earlier works, but to ensure no one breaks it while fixing something somewhere else in the code, maybe years after you wrote that, maybe not even knowing your code exists
  • 0
    @devnulli to give you a concrete example of why this doesn’t really hold water, my current team are 100% for full test-coverage (we’re currently around 70%), and to that end write complex code for simple thing just for the sake of testing.

    so the code is shit, and while they tells you tests improve the app, they make real shitty decision like “it’s ok to log out the user if sessions creation fails”, and other golden nugget of crappy UX that make me want to puke.

    it does illustrate what @monkeyboy says, aka lipstick on a pig doesn’t make anything but a pig with lipstick
  • 1
    Even though it sounds counterintuitive, writing tests actually makes you go faster. Why? Because imagine yourself in a following scenario.

    You wrote a project for 2 months with no tests which handles single payments. Everything works, client is happy all that. 2 years pass and they want to add recurring payments to the mix. You do NOT remember all of the code. You know you wrote it, its clean and all, but you cannot for the life of you remember all of the small rules and gotchas you encountered. What does that make you? Reaaaaally slowly add, triple check everything, go re-read all of the old code, refactor it then triple check everything again...

    Now imagine you covered it all with tests? You just code, then run tests, fix stuff, run tests and you are done (with new tests for the next time).

    Imagine how safe and secure that feels? Now thats the "speed" the tests offer.
  • 0
    @arekxv this is against YAGNI and KISS, you don’t write complex code & test just in case it could save you a few days 2 years from now .. 🤦🏻‍♂️

    i agree it does make sense to have integration tests on sensitive things like payment tho (not unit test)
  • 1
    @oreru the error sensors in cars an planes also arent' YAGNI and KISS

    i would not prefer to fit those AFTER something crashed
  • 0
    @devnulli it depends on your field too.
    i agree with you on sensitive application, but to my knowledge aircraft rely mostly on integrated hardware not software (might be outdated)
  • 0
    i should have added YMMV, i was mostly talking about unit test on smartphone apps.
  • 1
    @oreru thats right, for smartphone apps i would agree with you.
  • 0
    @devnulli
    Even with all of the YAGNI and KISS principles you employ you cannot do a multi-module complex project and keep track of everything all of the time, especially when working on a team. And would you rather cost clients a lot more money in damage repairs and lawsuits than just spend a bit more extra on few tests to help everybody catch bugs early and be safe?
  • 0
    @arekxv dude thats my point.
  • 0
    @arekxv i think that was for me. i agree having some test is good, esp. integration test.
    but in my experience unit test is shit. so it might depends on what we are really talking about here
  • 0
    i’ll post it here, it’s from one of the instigator of XP & scrum :

    https://rbcs-us.com/documents/...
  • 1
    @oreru
    there are many nice inputs in that paper. especially the "throw away tests that never fail" thing, i like it

    make sure you dont interpret this as making yourself a nice "test ice cream cone", it a well known anti pattern
Your Job Suck?
Get a Better Job
Add Comment