This blog is part of our blog series handling Profit Loans and Collaterals solution and working methods the development team has.
I started to work at Profit Software in August 2019. Prior to that, I wasn’t familiar with testing and now, months later I’m writing this text on my journey to becoming a full stack developer with an ambition towards testing.
We use Robot framework for interface and end-to-end testing. At first, Robot framework seemed a bit weird and clunky, but it quickly became more and more familiar to me. I use the ride editor as of now but I’m looking into VS code as its plugins get better. Programming with ride has been fun and has made me think of reusable component programming more so than normal (although I also develop with React).
Robot framework is built on suites which house the individual tests. Tests depending on tests in the same suite is acceptable in my mind but suites depending on other suites are a sure way to kill the whole idea of relying on these tests to give you usable data. I have the notion that tests should run independently from the get-go. If I run tests in a random order inside a suite, I would like to see them succeed. This gives me more confidence in the tests themselves.
I’ve also learned that the way you run tests is crucial. Let me give you an example: three developers checking Robot tests without mutually agreed way to do it. Might lead to a situation where comparing test results is impossible since there has been three ways of reviewing the process. Therefore, tests need to be standardised.
Also, making the same test over and over can become a problem. Imagine that 10 developers use pretty similar keywords in their specific tests. Then, database structure or user interface changes and maintenance becomes challenging. Solution: standard keywords to be used in tests so that test creation and maintaining those is a little bit easier for future developers.
We also want our tests to run fast and so we have included Pabot in our test execution chain. Pabot is an extension of Robot framework which allows us to split test suites into multiple processes making it possible to run tests in parallel execution. In this case it is important that suites do not depend on suites. If this is the case everything or most tests will fail.
Recently, I managed to optimise our robot tests from 40 minutes run time to 17 minutes. I observed that our test suites are becoming massive. After finding a proper profiling tool I searched the most used keywords and looked if there were any test sequences that could be removed or improved. With only a couple of small changes in critical places the tests speeded up with approx. 50 %. I also took one of our biggest test suites and chopped it up into two other suites. This helps Pabot to execute these tests in parallel and therefore faster. To explain the advantages of this one could say that a large bus was taking more and more passengers from each bus stop making the journey slow. After dividing passengers to several busses, travelling becomes more convenient.
When reflecting the journey, I’ve made good progress becoming more involved with integration testing, with the Robot Framework as well being a full stack developer. I have to say I like this so far; very challenging as the environment under development requires both business knowledge and technical expertise. Can’t wait to see what the future holds for me!
*) a concrete example of how a robot test is named
Read also previously published blogs: