Lessons Learned from Using Rapise to Develop/Test Rapise
September 10th, 2018 by inflectra
If you remember our blog post - The Cobbler's Children Have No Shoes - then you'll remember that we lamented that it's often hard to practice what you preach when it comes to yourself, because you are so busy delivering first for customers! Well, as a prequel to that, we realized that it was worth mentioning how ended up using Rapise to debug issues in Rapise itself!
Using Rapise to Develop Rapise
From very beginning we decided that Rapise will only be effective if we use it ourself to develop Rapise, and learn the pain points first hand.
This drives the design of Rapise, and the way we use it. Rapise has big internal part that we call the 'Engine'. It contains most of the logic for test execution and object recognition. And this part is implemented in JavaScript.
So the question is how to develop this JavaScript part? Our initial goal was to force all development to be done inside Rapise. So it has JS Editor with auto completion, folding and debugger.
So one can step inside the Rapise core and see its internals at very low level.
For example, you may step into Rapise core function Global.DoLaunch:
Why is it Important
Well, by using own tools we help drive its usability and stability.
Another side effect is supportability. Automated testing in many cases is going on in remote locations with restricted environments, and with limited access. An Application Under Test is often a legacy mashup of technologies.
Being able to develop and test Rapise using itself forces us to be creative to embrace automation as much as possible. And many times it helped us to survive by applying a patch or a fix internally before releasing it to our customers.
In tough situations, it helps us to investigate a problem. In critical situations, this helps us to change the core and make an ad-hoc fix without fear of side effects.
SpiraTest
SpiraTeam
SpiraPlan
RemoteLaunch
Rapise
KronoDesk
TaraVault
SpiraCapture
Cloud Services