Closed hyunji92 closed 7 years ago
Why don't you use random values? for debugging? You can just use debugging tools for that. random would not be problems for finding the wrong somethings.
I don't understand why using the concrete single value.
If you want to use concrete values, you should use testcases more thant one. Random value of course also not perfect, But, just one concrete value is so more weak for testing.
@mingrammer I don't agree with your opinion about random-value-testing. Using random value for testcase is usually considered as an antipattern. Assume that your testcase is randomly success and randomly fail. It means the test code being another debugging hell. The most important meaning of making testcase is making debug easy. But random-asserts makes hard to debug. See other's testcode. See the junit's testcode, see the django's testcode and see the golang's testcode. They don't use random values for testing. If we have to use random values for simple response-assert-testing, testcodes of many famous webframework must use random value but they don't. If we start using random value for simple response-assert-testing, then we have to use random assert on 80% of our test methods, which shadow the "really important part" and "truly business logic". Would you mind reconsidering to use random-assert after you read other super-geek's test codes?
@getogrand So, how do you choose proper testcases? In above, the subject='subject'
is not proper because the list page already has 'subject' text. So although if the return of list
view has no subject
value , the test will be passed.
@getogrand I agree with part of your opinion. The random values could not be reproduced, so, debugging being hard. Ok I got it. This is really important.
But, I don't know methodologies for choosing the proper testcases. Could you teach about that to me?
If I have written this testcase, I would just use different 'expectation string' for subject field. For example, subject='This is subject'
instead of subject='subject'
.
See this testcode of django framework itself. We can get the hint for writing tests from this..
@getogrand Well .. that is good. So, other values for testing should be changed. (username='username'
and others not proper)
And assertEqual(response.context['<context data key>'], expected value)
is better I think. It can check the value exactly. assertContains
is weak sometimes. Right?
@mingrammer I think it depends on case. If we just want to check context value of django request, assertEqual(response.context['<context data key>'], expected value)
is the answer. However if you want to check HTTP response or HTML data, assertContains
is needed.
There is big different between two ways above on application layering(abstraction layer?) perspective.
Former one is about python variable layer, latter one is about client(browser) layer.
Imagine that someone made his controller(view on django) well, but made lots of mistake on template. Latter will fail although former will success.
@getogrand The case of HTTP response also needs to use assertEqual()
sometimes (e.g. check the value of form
are rendered on template). But In our case, if the subject
value is like "This is subject", I'm ok for using assertContains
.
And we need to check the status code.
HaHa... There is so many conversations... Sorry, I just want to create minimum successful test, cause some reasons. First, there is no test case. It means we don't know we can make worked test or not. Second, I attend minimum working code when I start working. and I develop more and more. It is product code or test code. Third, teaching how to make test code on django.
I will apply your opinion on code and I will commit. Thank you.
I checked about fixture that is old way now. That is not recommending now on communities. (and twoscoop either.) I will create dummy data by factory boy, creating dummy data library.
@kyunooh Great! I am happy to know a much more nice way. P.S. The factory-boy is influenced by factory-girl which is a ruby❤️ library!
Please review and merge :D
42