Tuesday, June 13, 2017

Selenium3.4.0-Python3.6.1 : In Selenium-Python binding using unittest how do I decide when to use self.assertIn or assert

Leave a Comment

I am working with Selenium 3.4.0 with Python 3.6.1. I have written a script following the Python documentation through unittest module which is a built-in Python based on Java’s JUnit using geckodriver 0.16.1 and Mozilla Firefox 57.0 on Windows 8 Pro machine, 64 bit OS, x-64 processor. In my test method test_search_in_python_org() I have the following lines which works well:

    def test_search_in_python_org(self):       driver = self.driver       driver.get("http://www.python.org")       self.assertIn("Python", driver.title)       elem = driver.find_element_by_name("q")       elem.send_keys("pycon")       elem.send_keys(Keys.RETURN)       assert "No results found." not in driver.page_source 

When I am asserting the "page title" I am using: self.assertIn("Python", driver.title)

But, when I am asserting a string (my assumption), within the page source I am using: assert "No results found." not in driver.page_source

My question is what are the factors/conditions which decides whether I should use self.assertIn or simply assert?

Any suggestions or pointers will be helpful.

2 Answers

Answers 1

Looking at the Python unittest documentation and also recalling from the bunch of Django unittests that I once had to do here are my findings.

USE CASE:

First thing that is the most simple thing and in my opinion the biggest difference between the two, it where you can use each assert command. They are both interchangeably usable in the case of a test class, however, in order to use the assertIn command, the unittest library is needed. So, say I want to know if h is in hello, a simple way to do it through this command is:

class MyTestCase(unittest.TestCase):     def is_h_in_hello(self):         self.assertIn("h", "hello") 

and then I need to run tests, that is through unittest.main() in this example, in order to get my answer. But using the assert command, it is much easier for me to find out that h is actually in hello. Which is very simply done like so:

assert "h" in "hello" 

But essentially, both will give me the same result, however what distinguishes the two is the simplicity of use in the second method.

RESULTS:

The second difference I found was the readability of the results and the message on Python Shell. The unittest library is designed so that the commands are very specific and so if a test fails, you will receive a very clear message saying what went wrong. So say now you want to see if b is in hello. Doing it through the class method (simply changing "h" to "b", the message we get after running the test is:

AssertionError: 'b' not found in 'hello'  ---------------------------------------------------------------------- Ran 1 test in 0.038s  FAILED (failures=1) 

So it very clearly tells you: 'b' not found in 'hello', which is very convenient for you to see what exactly is the problem. But say you do the same process through the assert command. The error message generated is something like:

Traceback (most recent call last):   File "<pyshell#2>", line 1, in <module>     assert "b" in "hello" AssertionError 

Although it tells you that the error type (AssertionError), and the traceback, however it does not specifically tell you that "b" is NOT in "hello". In this simple case, it is very easy to look at the traceback and say oh, there's no b in hello! However in more complicated cases, it might be tricky to see why this error message was generated.

Overall, the two methods are very similar and will get you the result you want, but essentially it comes down to the little differences here and there, like how can you use less lines of code to get to the results and how straight-forward the Shell messages are.

Answers 2

In my opinion, assert is the built-in keyword in python which tells internal state of program. In other words, with the assert keyword, you can tell your code behavior. In your case, you should not use assert in testcase.

If You Enjoyed This, Take 5 Seconds To Share It

0 comments:

Post a Comment