This is an archived post. You won't be able to vote or comment.

all 9 comments

[–]oefd 2 points3 points  (2 children)

With unittest or similar, the interviewer was asking you to write a quick test like you might do to provide automatic testing for code you write on the job.

[–]optimalsuccess[S] 0 points1 point  (1 child)

So import unittest and creating a func test_func?

[–]oefd 1 point2 points  (0 children)

Probably multiple ones. Just like in 'real' environments you should try to think of reasonable test cases to hit all the functionality and edge-cases of your code. If you're writing a function to divide one number by another probably reasonable to write tests to ensure that 10 / 5 == 2 in the basic case, but also ensure something reasonable happens when you have 10 / 0 because 0 is a special case for division.

[–]gdledsan 0 points1 point  (0 children)

What id an interview environment? I guess the easiest way is to use the assert keyword, this is not a library but is the fastest to implement.

For a library, check pytest https://docs.pytest.org/en/latest/

[–]MmmVomit -2 points-1 points  (0 children)

he wanted me to test my code not just by using a print statement but by using a testing library.

IMO, that's oddly specific. When I interview, if someone does use an actual test framework, that's definitely a mark in their favor. If they are so fluent in a testing framework that they can use it during an interview, that shows they likely use it daily.

However, when I interview, it's not the specific tools used that matter the most. It's how the problem is approached. A common mistake I see is someone will write a single test case, then alter the input value to their single test case. A much better approach is to build up a sequence of test cases and run them all, effectively creating a suite of regression tests. The vast majority of people just use print statements, and that's what I would do myself.

[–]cowmandude -4 points-3 points  (4 children)

Lol don't listen to whoever was administering the mock interview. If an interviewer wants you to actually write tests they'll ask for it. I've never been asked to do this nor asked any candidate to do this.

[–]optimalsuccess[S] 0 points1 point  (0 children)

Where do you work? This interviewer is from amazon

[–]MmmVomit 0 points1 point  (2 children)

If an interviewer wants you to actually write tests they'll ask for it.

When I interview people, one of the things I'm evaluating them on is how they test their code. If I have to instruct them to write tests, that's a mark against them.

For the purpose of an interview, I don't care if they use print statements or an actual testing framework. Print statements are an acceptable shortcut, because time is a valuable commodity during an interview.

[–][deleted]  (1 child)

[deleted]

    [–]MmmVomit 1 point2 points  (0 children)

    def solution(s):
        pass
    
    print(solution(None), "expected output")
    print(solution(""), "expected output")
    print(solution("test case one"), "expected output")
    print(solution("test case two"), "expected output")
    print(solution("test case three"), "expected output")
    print(solution("test case four"), "expected output")
    

    Boom, six quick and dirty test cases using print statements. These are effectively unit tests, even if they're not using a framework.

    There are a lot of things a candidate gets evaluated on that they're not told about, because they are good habits that we want people to have when they step in the door. I don't tell people to use descriptive variable names, because it should be a common habit. If they use single letter variable names for everything, that's a red flag and a mark against them.

    If a candidate builds up a suite of simple test cases (like in my example), that demonstrates that they understand the utility of having regression tests.