Latest news about Bitcoin and all cryptocurrencies. Your daily crypto news habit.
Now continuing from Part 2, letâs revisit the test we were looking at:
Please check out Part 2, if you have not read it yet here: https://hackernoon.com/php-test-driven-development-part-2-unit-testing-c327ba3fbf14
We learned that asserts are statements that we use to verify or check if our output is what we need.
Here, we are checking if âtrueâ is true. Which is obvious duh, right? This test is really of no use to us. It does not test any of our code. It is just an example assert statement given to us by the Laravel framework.
Now, letâs make a practical use of assertTrue statement. Just for an example, letâs make a simple Class called Calculate.php under /app, one step inside of the root laravel folder âlaravel5â that we made on the previous episode. So the path is â/app/Calculate.phpâ. This is a simple demonstration class that just calculates the area of a square.
Now, you can get rid of the ExampleTest file as we donât need it. We will make a new test file to test the Calculate class.
Make a new file called âCalculateTest.phpâ under /tests/Unit folder with the code as follows:
Okay letâs go through this one by one. On line 4, we declare that we are going to use the App\Calculate class, using the âuseâ statement.
Line 7 we have the class name declared as âCalculateTestâ which is the standard format we will use for our tests. {Name of Class}Test
On line 9, we use a template method called âsetUpâ that is provided by PHPUnit. This method is called each time any tests are run in this class. This makes it effective to use as a common method that can share setup codes for this class. There is another template method we use called âtearDownâ and it is used to cleanup after a test is run. We do not need it here yet, but we will need it once we use mocks. You can read more about them here: https://phpunit.readthedocs.io/en/7.3/fixtures.html
On line 11, we can see that weâve initiated the class that we are about to test.
On line 14, we follow the standard naming that we discussed on the previous episode:
test_nameOfTheMethodYouAreTesting_WhenCalledWithSomeInput_ShouldReceiveSomeExpectedOutput
areaOfSquare is our target method that we want to test. âWhenCalledWithLength2â represents we are calling the method with length as 2 supplied. âReturn4â is what we expect to receive from the target method.
On line 16, we assign 2 as our length of square.
On line 17, we call the âareaOfSquareâ method with the assigned length.
Line 20 is where we assert that the given response is an integer.
Finally on line 21 we assert if the given response equals to 4, which is the required area of the square.
Now, letâs go back to our console and run âphpunitâ.
1 test ran and 2 assertions (âassertTrueâ and âassertEqualsâ) passed within it.
Congratulations, youâve written your first unit test. :)
Letâs say we want to test the same method more to ensure that it really does what it says. We may write another test duplicating the code but changing the input value and expected value. Below I added another test:
Now you should have 2 tests and 4 assertions passed.
Adding more tests for the same method makes the tests more reliable and takes care of edge cases. But of course, the tests have to be meaningful and test the right things.
Could we add more tests to this method? What if somebody called the method without providing any length? What if the length is negative, what will the output be? What if we supply a string instead of number to the method? We can ask ourselves these questions and write tests that matter for us.
Ok so letâs look at the case where it is called without any data.
On line 34 we declare our intention with âWhenCalledWithoutLengthâ and the expected result which is âThrowAnExceptionâ.
Line number 36 uses the expectException assertion expecting âArugmentCountErrorâ exception.
Line 37 does the same for the exception message.
We finally call the method without passing any length on line 39. This should give us the exception. When the exception is thrown, it will count as âpassed testâ as the test has completed our objective.
To run only this test we can use the --filter option this way:
phpunit --filter test_areaOfSquare_WhenCalledWithoutLength_ThrowAnException
When we run the above command, we get the following result:
Congratulations, your test passed. :)
Similarly, you can write tests for the case where the number supplied is negative or when something else is supplied instead of a number. And it is up to you to react to those things in the code or to let it throw an exception if that is what you intended it to happen.
So go ahead, start writing extra tests for the method. And also you can start writing tests for other functions that calculate area of circle, rectangle etc.
If you face any issues or have questions, please feel free to write in the comments below.
On the next part we will be learning about mocking. This is another crucial topic that we will need in our arsenal for unit testing.
Please donât forget to share and give claps if you found it helpful. Until then, see you. Have a great day! :)
PHP Test Driven Development Part 3: Unit Testing Continued was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.
Disclaimer
The views and opinions expressed in this article are solely those of the authors and do not reflect the views of Bitcoin Insider. Every investment and trading move involves risk - this is especially true for cryptocurrencies given their volatility. We strongly advise our readers to conduct their own research when making a decision.