• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!
Collapse

You are not logged in or you do not have permission to access this page. This could be due to one of several reasons:

  • You are not logged in. If you are already registered, fill in the form below to log in, or follow the "Sign Up" link to register a new account.
  • You may not have sufficient privileges to access this page. Are you trying to edit someone else's post, access administrative features or some other privileged system?
  • If you are trying to post, the administrator may have disabled your account, or it may be awaiting activation.

Previously on "How to fail a technical test"

Collapse

  • MicrosoftBob
    replied
    Originally posted by minestrone View Post
    For all the tested systems I have worked on I can't honestly say that any of them have gained in any way from testing. Far too much code is written, it is never maintained only added to, what they test is usually code for testing sake rather than testing functionality and very rarely does it actually find a fault that would have went into production that would not have been spotted.

    Now we can get into pissing competitions about noddy project but that is my experience working for 15 years on code tested code for clients big and small on projects big and small.

    For instance my last project had testing on live user data, if the live user made a change and the DB was copied onto test the Jenkins builds would fail. Now that is an extreme example but that is the kind of stuff I see a lot of.

    Really I think we should concentrate on getting people to write code safely and intelligently first before we let them lose with test cases that only give them a false sense of security and another bundle of tulipe code to maintain.
    I've seen enough real world examples where regression testing would have maked a product useable rather than become more buggy as each new developer tried to maintain a system

    The problem is not testing per se, but people blindly following processes

    Leave a comment:


  • minestrone
    replied
    Originally posted by russell View Post
    Then you can only have worked on noddy projects, try working on a complex system with many potential scenarios and then making a change. Now do all the scenarios that worked before still work?
    For all the tested systems I have worked on I can't honestly say that any of them have gained in any way from testing. Far too much code is written, it is never maintained only added to, what they test is usually code for testing sake rather than testing functionality and very rarely does it actually find a fault that would have went into production that would not have been spotted.

    Now we can get into pissing competitions about noddy project but that is my experience working for 15 years on code tested code for clients big and small on projects big and small.

    For instance my last project had testing on live user data, if the live user made a change and the DB was copied onto test the Jenkins builds would fail. Now that is an extreme example but that is the kind of stuff I see a lot of.

    Really I think we should concentrate on getting people to write code safely and intelligently first before we let them lose with test cases that only give them a false sense of security and another bundle of tulipe code to maintain.

    Leave a comment:


  • xoggoth
    replied
    Code should always be tested as quickly as possible as tiny errors spread and grow into big ones if left long enough. My code was always near perfect, if significant errors were found it was only because lazy testers did not test them quickly enough.

    Leave a comment:


  • suityou01
    replied
    Why give him the job? If he was being "clever", in a "trickie dickie" way he should have supplied the correct answer as well, then pointed out the improvement that could be made in the interview question.

    All he has demonstrated is he is a drone that takes the path of least resistance.

    Leave a comment:


  • stek
    replied
    Originally posted by James Tiberius Kirk View Post
    "Klingons don't take prisoners"
    Classic sleeper sockie!!

    160 posts since 2006, no one sleeps a sockie like that, I suspect admin foul play....

    if it's real, fair play...

    Leave a comment:


  • Boney M
    replied
    Give him the job

    Leave a comment:


  • hyperD
    replied
    Originally posted by stek View Post
    Kobayashi Maru?
    Hehe!

    Leave a comment:


  • MyUserName
    replied
    Originally posted by James Tiberius Kirk View Post
    "Klingons don't take prisoners"
    Kirk does say this in WoK but the Klingon Captain Kruge in The Search for Spock killed his helmsman when he blew up the Grissom because he wanted prisoners.

    Leave a comment:


  • doodab
    replied
    Originally posted by russell View Post
    Then you can only have worked on noddy projects, try working on a complex system with many potential scenarios and then making a change. Now do all the scenarios that worked before still work?
    That doesn't change the fact that the code that tests that the change didn't break anything is mostly tulipe.

    I'd recommend the book XUnit Test Patterns to those suffering with this. It has some useful stuff in it.

    Leave a comment:


  • russell
    replied
    Originally posted by minestrone View Post
    Test classes are usually a pile of tulipe anyway,
    Then you can only have worked on noddy projects, try working on a complex system with many potential scenarios and then making a change. Now do all the scenarios that worked before still work?

    Leave a comment:


  • James Tiberius Kirk
    replied
    Originally posted by stek View Post
    Kobayashi Maru?
    Originally posted by zeitghost
    "Klingons don't take prisoners"

    Leave a comment:


  • Pogle
    replied
    Originally posted by eek View Post
    Client co has one of he better technical tests I've seen. It's quite simple here is some tulip code and some failing unit tests you need to ensure the code passes the tests.

    Today we got a contractor who took a different approach. Having spent ages trying to work out what to do he changed the unit test to ensure it instantly passed
    I think i worked with him on my last contract...

    Leave a comment:


  • northernladuk
    replied
    Originally posted by stek View Post
    Kobayashi Maru?
    LOL. That is the first thing I thought when I read this.

    Leave a comment:


  • GazCol
    replied
    Originally posted by eek View Post
    Client co has one of he better technical tests I've seen. It's quite simple here is some tulip code and some failing unit tests you need to ensure the code passes the tests.

    Today we got a contractor who took a different approach. Having spent ages trying to work out what to do he changed the unit test to ensure it instantly passed
    Top marks?

    If the brief is make sure the code passes the test hasn't he done the lateral or, rather, correct action in changing the test rather than changing the code?

    Leave a comment:


  • d000hg
    replied
    Originally posted by minestrone View Post
    Test classes are usually a pile of tulipe anyway,
    Cases.

    There IS the problem that bad coders will write bad tests which don't properly cover their bad code and fail to show how bad their code is. While good coders will write good tests which demonstrate how good their code was in the first place.

    Leave a comment:

Working...
X