2. Who Am I?
• Nir Tayeb - 25 years old
• Senior Full stack engineer at Tapingo
since November, 2014
• nir@tapingo.com, nir.tayeb@gmail.com
3. The situation
The company new senior developer (A.K.A
me) got a task to solve a big operational
issue in the core system
4. • The issue happened in one of our most
valuable venues
• The issue happened on specifics conditions
• Failing in fixing it right may ruin the whole
ordering system and affect all the rest of the
venues
• The last senior developer who tried to solve it
failed in Production
5. No unit-testings are available
That’s means I cannot make sure I don’t f*ck the whole ordering system
6. So for every change I made in the flow,
I’ve created a test to make sure it get the right results
7. Divide and Conquer
• The system is big and complex
• The function[s] I’ve wanted to tests are
depend on many external which are present
in cache/RDBMS/Mongo
• The function[s] I’ve wanted to tests are called
from different processes on different servers.
8. The main key to success in testing
is making your code more
MODULAR
9. Divide and Conquer
• Make the code more modular:
– Create function for bringing data
– Create function for verifying conditions
• In the test – patch those functions to get
specific “events”
10.
11. Time Travel
• Datetime cannot be patched
• Instead of using datetime.now/utcnow
direct – make a function get_now
• In the test – patch this function return
value to the specific time you want
12.
13. Testing in messaging
environment
• Separate the processing code to separate
function from the function which get the
message
• In the test – call to each processing
function one after one
14.
15. Every time a bug is encountered by the
QA (good) or in Production (bad)
make a test which check the bug – so it
won’t happen never again!
16. Results
• In 2 weeks we solved the issue and it got
to production successfully
• About 99% of the code is already tested
(in the area I worked on)
• The code could easily refactored
