4# Unit Test: F.I.R.S.T Principles
Last Thursday, we have this lecture from partner in industry, KMKLabs. I found myself interested when the instructor explained about Clean Code. So, i tried to browse in well-known massive search engine, Google. There, I found about F.I.R.S.T Principles. It takes milliseconds for me to just click it out and read the page.
It is a principles for high standard unit testing. In Clean Code book, it will be detailed in chapter 9.
Well, let me explain little that I read and understand.
Quick, negation of slow, yap! Fast! The test must be fast.
If you hesitate to run the tests after a simple one-liner change, your tests are far too slow. Make the tests so fast you don't have to consider them.
I understand what they mean fast is because the test isn't running for only few functions. There will be tons of functions that need to be tested. However, I am amazed that the test need to run faster than a second, faster than a half second or quarter-second. It’s quite fast then..
A test method should do the 3 As: stands for Arrange, Act, and Assert.
Arrange: The data used in a test should not depend on the environment in which the test is running. All the data needed for a test should be arranged as part of the test.
Act: Invoke the actual method under test.
Assert: A test method should test for a single logical outcome, implying that typically there should be only a single logical assert. A logical assert could have multiple physical asserts as long as all the asserts test the state of a single object. In a few cases, an action can update
multiple objects
Each test class name and test method name should notified what is wrong and where. So, the tests isolate failures. If it isn't, then it should be replaced by smaller and more-specific test.
The test has to be able to be run repeatedly without any intervention. It also may not depend on any data in the environment in which it is run because those resources might not always be available.
The test needs to inspect fail or pass by itself. So there is no manual inspection needed to check whether the test has passed or failed.
This is how TDD should be done. The test needs to be made immediately before the function has been made. It is like what TDD taught, Test Driven Development.
My team has not implemented this, yet we are working on it.
http://agileinaflash.blogspot.co.id/2009/02/first.html
https://github.com/ghsukumar/SFDC_Best_Practices/wiki/F.I.R.S.T-Principles-of-Unit-Testing
