• (cs)

    TDWTF commenting system sinks to new lows: if you just click on the link, it takes you to a page which informs you that it's a private comment thread and you need to sign in.

  • Miriam (unregistered)
    CommentSection cs = new CommentSection();
    cs.setType(CommentSection.Discourse);
    assertEquals(CommentSection.Discourse, cs.getType());
    

    Still better than no tests at all~

    And Discourse not wanting people to comment is hilariously ironic.

  • A Guy (unregistered)
    Josh's team has an offshore group that "helps" with our development tasks.
    that explains quite a lot actually
  • (cs)

    Assertion failed, expected [proper comment section] but got [Discourse]

  • n/a (unregistered)

    TDWTF: your friendly provider of 75% of the unit test coverage for Discourse.

  • Smug Unix User (unregistered)

    Assert.isFalse(Comments.RequiresSignIn)

    1 test failed...

  • (disco)

    Frist? Can you assert it for me?

  • (disco) in reply to chreng

    I can assert that you are sceond.

  • (disco)

    I work in SQA. This is not even remotely unusual. Even for in-house developers.

    "What do you mean it's not testing anything? Look, it makes a call to the function and dumps the output to the screen. That's a test."

  • (disco)

    What I've noticed is that you need to do some hand-holding when introducing new concepts. Don't just tell them they need to add asserts and tell them about the great benefits of asserts. An assert can be for a precondition that shouldn't happen. It shouldn't be to verify the impossible happened. Sure. Testing getters and setters should be done somewhere, but not in every test. At our work, we do test all the getters and setters are doing what is expected. We also verify when set fails, it doesn't corrupt what was there.

    Unfortunately, we have some very verbose QA tests that might take hundreds of lines to verify one functionality. As a developer we tried to show them it could be done in 10, but it is hard to change process now.

  • saluto (unregistered)

    Assert.isTrue(Comments.HasPaging)

    Another test failed...

  • (disco)

    A couple of things:

    If you're continuing to use an offshore team which seemingly has a long history of reducing productivity, you're doing it wrong. But I'm willing to bet the code isn't ever completely broken, they just take a few retries to get it fully functional.

    Demanding that "thou shalt write unit tests for all code" doesn't fix the problem anyway. They did exactly what you asked, after all. What you wanted was for them to "write tests which enforce that the code works as it's intended, and meets all requirements". You don't even care if they're unit tests specifically.

    Sometimes I wonder how the developers in these stories survive (either career or sanity wise) being so smug.

  • (disco) in reply to HaximusPrime
    Nprz:
    What I've noticed is that you need to do some hand-holding when introducing new concepts.
    HaximusPrime:
    Sometimes I wonder how the developers in these stories survive (either career or sanity wise) being so smug.
    I find it interesting that we already have two posts that seem to put the blame on the contracting company, and not on the offshore team.

    Interesting because in no other contracting situation would you see something like that.

    • I don't have to tell the builder building my house "but make sure the walls are straight"
    • I don't have to tell my garage "but test-drive the car after you have fixed the brakes"
    • I don't have to tell the cook "but put a timer next to the pan, so that you know when the steak is medium"

    But with offshoring / outsourcing everybody seems to take it as the norm that the people contracted have such a low professional standard that you must babysit them.

    Quite an argument against offshoring, if you ask me.

    Filed under: Been there, done that, learned that "just improvise something" is not a valid spec.

  • (disco)
    1. Offshore developers have never seen an assert.
    • Josh sends them a message telling them to use asserts, and as an example includes a snippet like the one in the article: "assertEquals('name', thing.getName())";
    • Not being very bright people, offshore developers can't think of any more places where you could use them, so they just stick with that.
  • (disco)

    Onde I joined a project where unit tests followed this pattern:

    Object[] arguments = generateAllPossiblyImaginableArgumentPermutations();
    for (Object arg : arguments) {
         try {
               Object return = testedObject.testedMethod(arg);
               assertNotNull(return);
         } catch (Throwable t) {
         }
    }
    

    Passing every possible parameter makes the code go through all the possible execution paths. And the method never returns null, it either returns "something" or throws an exception, so the assert is guaranteed to pass.

    Result: easily meeting the customer requirement of 100% test coverage, with 100% success.

    And yes, this was an offshore team.

  • (disco) in reply to HaximusPrime

    Sounds like : You will not lose weight by standing more frequently on a scale

  • (disco)

    Just another example of "you get what you pay for."

    Hire cheap developers, you get cheap code. You ask for unit tests, you get cheaply written unit tests.

  • (disco) in reply to faoileag

    A couple of points:

    1. If the builder building your house is not making the walls straight, it is his fault and you should probably fire him. So it is argument against this particular offshore agency, certainly.

    2. This is not analogous to hiring a general contractor to build a house. I an offshoring case, you're hiring an outside agency to replace some function which otherwise would be done internally, which means you effectively are the general contractor. A general contractor who doesn't closely manage his subcontractors is likely to have serious problems if he's not very very lucky.

    I do agree you shouldn't have to hand-hold them, though; if you have to hand-hold them, there's something seriously wrong and the entire relationship should be re-evaluated. On the other hand, sometimes you don't have much choice. If you're left managing a subcontract dictated by high mucky-mucks above you who negotiated a ten year deal that would be costly to back out of, then you're kind of stuck with it.

  • (disco) in reply to faoileag
    faoileag:
    But with offshoring / outsourcing everybody seems to take it as the norm that the people contracted have such a low professional standard that you must babysit them.

    Unfortunately, experience has shown that to be the norm. It shouldn't be, but it is.

    faoileag:
    Quite an argument against offshoring, if you ask me.
    I agree, but I have no input into those decisions. The senior manglement only sees that they can hire off-shore devs for a scoop of rice and a piece of naan per day; 100 of them cost less (money) than 1 competent on-shore dev. They never see the cost of the WTFy but sort-of-working result.
  • (disco) in reply to calliarcale
    calliarcale:
    I an offshoring case, you're hiring an outside agency to replace some function which otherwise would be done internally

    In our case, it's our own office in $thirdWorldCountry, or rather $thirdWorldCountry[$n], since we have more than one. So we get to see more of the WTF behind the WTF. At least some of the devs are capable of doing good work, but their managers are in favor of taking shortcuts, and senior on-shore management isn't willing to fight the local management and "just enough to get by" culture.

  • (disco) in reply to faoileag
    faoileag:
    I find it interesting that we already have two posts that seem to put the blame on the contracting company, and not on the offshore team.

    The article states it is an offshore team, not an outsourced company. So it is a bit different in that the onshore team might have to do some more initial teaching to make sure the remote team is following procedures.

    If it were a contracted company and they produced poor results, then fire them and find someone else that can do the job. Yes, there is a difference between contractors and employees whether or not they are local or remote. Being remote and in a completely different timezone means there is probably going to be things that are disparate, but that is what is the companies responsibility.

    (And I say this as someone who is both remote and in a large company with maybe 50+% remote in many different regions).

  • (disco) in reply to faoileag
    faoileag:
    I don't have to tell the cook "but put a timer next to the pan, so that you know when the steak is medium"

    A timer is a terrible way to determine when your steak is cooked right

  • (disco) in reply to Nprz
    Nprz:
    The article states it is an offshore team, not an outsourced company.So it is a bit different in that the onshore team might have to do some more initial teaching to make sure the remote team is following procedures.

    Still, you'd expect your team, offshore or not, to have basic programming knowledge (which writing sensible unit tests constitutes). Otherwise, they shouldn't be hired in the first place.

  • (disco) in reply to Maciejasjmj
    Maciejasjmj:
    Still, you'd expect your team, offshore or not, to have basic programming knowledge (which writing sensible unit tests constitutes). Otherwise, they shouldn't be hired in the first place.

    I've found that offshoring and outsourcing cause you to become a teacher with students that you are paying to learn, more than anything.

  • (disco) in reply to Maciejasjmj
    Maciejasjmj:
    Still, you'd expect your team, offshore or not, to have basic programming knowledge (which writing sensible unit tests constitutes). Otherwise, they shouldn't be hired in the first place.

    Sure. I have noticed at my company, it is hard to fire someone once they are hired though. And when doing an interview involving programming, there is usually not enough time to cover whether they can program very well. Sometimes they ace the interview and write very crappy code, or good code but it takes them a century. Or their coding skills are fine, but their English comprehension is poor (because they grasped enough during the interview to do whatever basic question was asked).

    Hence all the "tales from the interview" that would show up here. (and uhh, what chubertdev said)

  • (disco) in reply to chubertdev

    The real WTF here is that if you are working with an outsourced team, you should be writing the tests yourself, and they should be writing the code that passes those tests. Your spec should be your test. That said, you must make sure your test is thorough, and when you accept code, you must run some hidden tests as well to make sure they didn't just program 'to the test'.

  • (disco) in reply to spiderx
    spiderx:
    The real WTF here is that if you are working with an outsourced team, you should be writing the tests yourself, and they should be writing the code that passes those tests. Your spec should be your test. That said, you must make sure your test is thorough, and when you accept code, you must run some hidden tests as well to make sure they didn't just program 'to the test'.

    And then they never pass tests, you get blamed for holding up the project, and you have to fire up Word...

  • (disco) in reply to chubertdev
    chubertdev:
    offshoring and outsourcing cause you to become a teacher with students that you are paying to learn

    It also seems to be common that they get hired, get company-paid training in $skill, quit, and get another job where they can get paid more because they can now put $skill on their CV and maybe talk their way through a couple of interview questions.

  • (disco) in reply to HardwareGeek
    HardwareGeek:
    It also seems to be common that they get hired, get company-paid training in $skill, quit, and get another job where they can get paid more because they can now put $skill on their CV and maybe talk their way through a couple of interview questions.

    Which is perfectly fine for explicitly entry-level positions. But when you have HPCs who can't code their way out of a wet paper bag, it's a huge WTF.

  • (disco)

    The number of responses per article has been reduced drastically and apparently the people that tend to sign up for this kind of thing rather than leave anonymous comments also tend to be the ones to blame the submitter rather than the WTF the submission is about. Lose/lose!

    Needs more anon trolls saying stupid things we can all laugh about.

  • (disco) in reply to darkmatter
    darkmatter:
    The number of responses per article has been reduced drastically and apparently the people that tend to sign up for this kind of thing rather than leave anonymous comments also tend to be the ones to blame the submitter rather than the WTF the submission is about. Lose/lose!

    Needs more anon trolls saying stupid things we can all laugh about.

    You can tell on the front page which system is used for comments simply based on the number of comments.

    Guideline 28: Don't force registration

    http://www.amazon.com/Defensive-Design-Web-improve-messages/dp/073571410X

  • (disco) in reply to DrakeSmith

    Note to self: never eat a steak @faoileag or anything else for that matter.

  • Shawn Sean (unregistered)

    [quote user="chubertdev"][quote user=HardwareGeek] It also seems to be common that they get hired, get company-paid training in $skill, quit, and get another job where they can get paid more because they can now put $skill on their CV and maybe talk their way through a couple of interview questions. [/quote] Which is perfectly fine for explicitly entry-level positions. But when you have HPCs who can't code their way out of a wet paper bag, it's a huge WTF. [/quote] I can't code my way out of a wet paper bag (in fact it seem to me a task that really doesn't len itself well to programming). Maybe if I had a robot....

  • Shawn Sean (unregistered) in reply to Shawn Sean
    Shawn Sean:
    chubertdev:
    HardwareGeek:
    It also seems to be common that they get hired, get company-paid training in $skill, quit, and get another job where they can get paid more because they can now put $skill on their CV and maybe talk their way through a couple of interview questions.
    Which is perfectly fine for explicitly entry-level positions. But when you have HPCs who can't code their way out of a wet paper bag, it's a huge WTF.
    I can't code my way out of a wet paper bag (in fact it seem to me a task that really doesn't len itself well to programming). Maybe if I had a robot....
  • (disco)

    My experience with offshore developers: they build exactly what you ask them to build. No more and (mostly) no less. Don't expect the same level of thought going into what they build as from the in-house team. The in-house team have much more at stake than the offshore team.

  • (disco) in reply to Luhmann

    I'd never eat an @faoileag either.

  • cyborg (unregistered) in reply to Shawn Sean
    Shawn Sean:
    Shawn Sean:
    chubertdev:
    HardwareGeek:
    It also seems to be common that they get hired, get company-paid training in $skill, quit, and get another job where they can get paid more because they can now put $skill on their CV and maybe talk their way through a couple of interview questions.
    Which is perfectly fine for explicitly entry-level positions. But when you have HPCs who can't code their way out of a wet paper bag, it's a huge WTF.
    I can't code my way out of a wet paper bag (in fact it seem to me a task that really doesn't len itself well to programming). Maybe if I had a robot....

    Can you quote your way out of a paper bag?

  • (disco) in reply to Drakkie
    Luhmann:
    Note to self: never eat a steak @faoileag or anything else for that matter.
    Drakkie:
    I'd never eat an @faoileag either.
    I can live with that.
  • (disco) in reply to DrakeSmith
    DrakeSmith:
    A timer is a terrible way to determine when your steak is cooked right

    Is a timer even worth if if you want your steak blue, as it should be.

  • (disco) in reply to spiderx
    spiderx:
    Your spec should be your test. That said, you must make sure your test is thorough, and when you accept code, you must run some hidden tests as well to make sure they didn't just program 'to the test'.
    If your spec is your test, then any hidden test *should* fail. Programming 'to the test' is the whole point of test driven development.

    TRWTF is this crappy new comment system. It even captures ctrl-f making it much harder to do a useful search.

  • ideo (unregistered) in reply to cyborg
    cyborg:
    Shawn Sean:
    Shawn Sean:
    chubertdev:
    HardwareGeek:
    It also seems to be common that they get hired, get company-paid training in $skill, quit, and get another job where they can get paid more because they can now put $skill on their CV and maybe talk their way through a couple of interview questions.
    Which is perfectly fine for explicitly entry-level positions. But when you have HPCs who can't code their way out of a wet paper bag, it's a huge WTF.
    I can't code my way out of a wet paper bag (in fact it seem to me a task that really doesn't len itself well to programming). Maybe if I had a robot....

    Can you quote your way out of a paper bag?

    Apparently he can't. But at least with Community Server he can screw up anonymously! :-)

  • (disco) in reply to PJH
    PJH:
    Is a timer even worth if if you want your steak blue, as it should be.

    I'm totally at a loss of what that is saying - it starts as a question, ends with an assertion, and I don't know what a blue steak is...

  • (disco) in reply to DrakeSmith
    DrakeSmith:
    I'm totally at a loss of what that is saying - it starts as a question, ends with an assertion, and I don't know what a blue steak is...
    Raw. [image] [image]
  • (disco) in reply to PJH

    Never heard that term used that way - wonder if it's a cultural thing.

  • (disco) in reply to DrakeSmith

    The term is known to almost all the chefs I've used in UK, US and NO, so it's not that, erm, rare.

  • (disco)

    Well done isn't well.

  • (disco) in reply to DrakeSmith

    Si vous ne savez pas c'est quoi exactement de la viande blue vous pouvez cherchez la réponse sur votre site internet préférer. Un steak blue et encore moins cuite que un steak saignant. C'est a dire que c'est pratiquement pas quite. Si vous doutez quand vous faits votre commande demande à point, c'est entierement cuite mais pas tros seche.

    http://en.wikipedia.org/wiki/Temperature_(meat)

    dhromed:
    Well done isn't well.
    I would even say that well done is hardly ever done well.

    Filled under: I think I heard my French teacher throw up

  • (disco)

    Just stumbled over coworkers unittests:

    1. Insert values via sqlCommand,
    2. Retrieve them as object via entitycontext
    3. Compare if the values are still the same.

    At least i can be sure the Database doesnt manipulate data when inserting :frowning:

  • (disco) in reply to PJH
    PJH:
    The term is known to almost all the chefs I've used in UK, US and NO, so it's not that, erm, rare.

    I've been a grill cook in a steak house and never heard called blue.

  • (disco) in reply to DrakeSmith

    I'd never heard it before. I googled it and stuff seemed to say it came from French (i.e., bleu). I don't usually think primarily in terms of temperature, so this seems wrong.

Leave a comment on “Self-Asserting Test Supremacy”

Log In or post as a guest

Replying to comment #440035:

« Return to Article