code could open up significant security vulnerabilities it was essential that we thoroughly locked down our implementation. As such we aimed to test all of the behaviours of our API and pushed for a very high code coverage on the API implementation. To do this we used the same test frameworks and tools we used to test our web application, RSpec and simplecov. Figure 102 shows a screen-shot of the output produced by simplecov. As can be seen we achieved 100% code coverage on our application. Given that the application did not contain many files or parts, the majority of our testing took place in the key pair controller.rb file, where the logic for our API lives. Although code coverage does not provide an absolute indicator of how well a file is tested, it does give us some idea about the areas that need improvement. As such we used simplecov to help guide us when writing tests for the most critical areas of our API.
Figure 102: A screen-shot of the code-coverage of our key store API. Figure 103 shows a code snippet of a test for the API method that updates the total amount matched for a bet. The test in the snippet checks that setting the amount matched to a value lower than the amount already matched fails, returning a 400 bad request error. As can be seen in the snippet, a bet is created that has received a payment of 10,000 satoshi. We set the amount matched for that bet to 5,000 satoshi. An API call is then made to update the amount matched to 4,950 satoshi. Because this new amount is less than the previous amount matched (which doesn’t make sense because the amount matched should always be increasing) the API call fails. 1 ... 2 i t ” s h o u l d not a c c e p t an i n v a l i d t o t a l amount matched : amount matched l e s s than a l r e a d y matched ” do 3 e n c r y p t e d b e t a d d r e s s = e n c r y p t s t r i n g (TEST BET ADDRESS) 4 e x i s t i n g b e t = c r e a t e n e w b e t (TEST BET ADDRESS) 5 s e t b e t p a y m e n t r e c e i v e d ( e x i s t i n g b e t , ” 10000 ” ) 6 s e t b e t t o t a l m a t c h e d ( e x i s t i n g b e t , ” 5000 ” ) 7 n e w t o t a l m a t c h e d = ” 4950 ” 8 encrypted new total matched = e n c r y p t s t r i n g ( new total matched ) 9 10 p o s t ’ / a p i / update matched ’ , : f o r m a t => ’ j s o n ’ , : b e t a d d r e s s => e n c r y p t e d b e t a d d r e s s , : t o t a l m a t c h e d => e n c r y p t e d t o t a l m a t c h e d 11 e x p e c t ( r e s p o n s e . s t a t u s ) . t o eq ( 4 0 0 ) 12 e x p e c t ( j s o n [ ” e r r o r ” ] ) . t o eq (TEST INVALID ARG STRING) 13 end 14 . . .
Figure 103: A code snippet of an API test that tests a call to update the amount matched for a specific bet. This test checks to see that setting the amount matched to an amount less than the current amount matched fails.
115