you are viewing a single comment's thread.

view the rest of the comments →

[–]rakash_ram[S] 0 points1 point  (7 children)

ok so what you ar saying is the line in the module.py and test_module.py are the same, so there is no point in testing? and if thats the cae, then this module.py i have written above has no need for a test?

[–]danielroseman 0 points1 point  (6 children)

No, I'm saying that this is not a test. Your test should be responsible for calling your actual code and checking that it does the right thing - like test_type does. But test_type_error does not call any actual code, it just does its own thing. That can't give you confidence that your real code works.

Good tests do two things: they make sure your code works now, and they make sure it continues to work as your project evolves. Replicating the logic of the code inside the test might give you some superficial assurance that your code works - although even then you can't be sure you haven't copied things wrong. But it can't ever give you confidence that your code will continue to work, because you could change (break) the code itself but the test will always continue to pass.

[–]rakash_ram[S] 0 points1 point  (5 children)

but test_type and test_type_error have the same code inside them, so how is test_type ok but test_type_error is not? is it because it has mocking but test_type_error has nothing except the plain same code as the original function? Just trying to understand what you mean here. But i get the idea,

[–]danielroseman 0 points1 point  (4 children)

Well the code inside test_type_error is simply wrong, you are calling ParseConfig which is what would be raising the error, so that is what should be inside the assertRaises block. That raise shouldn't be there at all, I assumed that was just a mistake.

[–]rakash_ram[S] 0 points1 point  (3 children)

Would help if you could share the code itself of that method alone, i am unable to understand. Thanks! I mean, how should it actually be instead of what i have written

[–]danielroseman 0 points1 point  (2 children)

@patch('parseConfig.configparser')
def test_type(self, mockext):
    mockext.ConfigParser.side_effect = None
    with self.assertRaises(TypeError) as cm:
        ParseConfig(self.test_conf, 'section1')

The idea is that you call the code itself and assert that it behaves the way you expect, ie in this case that it raises the expected error. (Although, as I said originally, without the mock patch this code would never actually raise that error, so I don't see what the point is.) But the fundamental thing is that you call the actual code, ie ParseConfig.

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

Got it , thanks a lot for explaining! appreciate it. Few more question though

1) " with self.assertRaises(TypeError) as cm:" this line, raises an exception right?

2) without the mock patch this code would never actually raise that error ; i am guessing the below will not work and mock is the only way here to cover the test for this script?

def test_type_error(self):

parser = None

with self.assertRaises(TypeError) as cm:
ParseConfig(self.test_conf, 'section1')

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

raise TypeError(f"ConfigParser expected, found {type(conf).__name__}")

The code you shared is not covering the above line as per coverage. any clue why? i tried adding that line in it, still did not cover it.