I thought I'd lift a follow-up response to Pavel into its own standalone thread rather than continue it there.I'm personally using recording only occasionally, but I use Recording modules a lot! I just fill them with actions manually.
I replied that,
Pavel responded in full as follows.That's very interesting, Pavel. I've been using lots of re-usable and very atomic code modules - some incredibly simple, others less so. But I'm hoping to expose our Ranorex tests to more folks in our organisation soon, so having alternatives for them would help matters a lot.
I started off learning Ranorex with recordings, peered at the code, then never touched them again once I had figured out the Ranorex API. But I'm off to experiment with Recording Modules now that you've suggested it, so thanks for that.
But specifically he mentioned that,This is also my aim, to introduce TA to people, who may be less coding-skilled, yet excellent manual testers. A lot of guys in our organization are great testers, but many of them don't have any coding background and they are often scared of it From what I found, it's much easier for them to start with Recording modules. Showing them a project full of code modules filled with meaningless lines of texts would most probably scare the sh... out of them Recordings are definitely easier to read and understand, than code. And at some point in time, they will anyway start with coding simple conditions and loops and eventually learn more complicated things. The first thing I always teach new person interested in TA is that recordings must be atomic (at max 10 actions per recording module). And the next thing, that repo must be clean and tidy, with no generic names and minimum of indexes and zero dynamic IDs All in all, code-less TA is a myth If one wants to become a successful TA person, certain coding skills are required. On the other hand, I think that coding everything from the ground up only slows the things up and may eventually introduce more bugs than with auto-generated recording modules?
Yes, that's something I've been scared of. I've been heavily tree/folder structuring my numerous small code modules to try and make them easy to locate and intuit their likely presence in my code module library. Easy for me to find because I know exactly what I've written. A challenge for anybody unfamiliar with my efforts.From what I found, it's much easier for them to start with Recording modules. Showing them a project full of code modules filled with meaningless lines of texts
But I have been beginning to consider that I'd need to continue creating these code modules for TA-ers, hence my interest in equally atomic Recording Modules. I can totally see them creating those. I want to investigate parameterising them, something I use a lot with my code modules. I've not got into that just yet - other jobs to do first.
Oh, Yes! I learned that lesson right from the start of my Ranorex adventure!!! To the point that I've even written some code modules which sanity check my repositories to verify that obvious errors have not crept in by accidents. So every test run Ranorex validates the repositories that I'm going to use. I look for:And the next thing, that repo must be clean and tidy, with no generic names and minimum of indexes and zero dynamic IDs
- dynamic class names (thanks, MFC!)
- dynamic IDs
- certain class names which might indicate a debug build was used to build the repository item
- potential issues with drop-down lists
- and unwanted wildcards in RxPaths.
I'd argue the other way actually. As mentioned originally, back in my early days with Ranorex I literally reviewed the code behind a recording, saw how Ranorex was achieving things, and started writing code modules 100% of the time after that. I've been able to augment several of these code modules to cope with awkward AUT-specific scenarios which I might struggle with otherwise. Just one example, of many, which I happened to have to deal with earlier this morning was a clipboard operation throwing exceptions when I accidentally left a TightVNC session open.On the other hand, I think that coding everything from the ground up only slows the things up and may eventually introduce more bugs than with auto-generated recording modules?
I've also hoisted a lot of common code out of my code modules during refactoring. It's an ongoing process of maintenance, but I think I have a lot of nuanced cases where I've managed to smooth out behaviour to make an otherwise fairly atomic code module perform reliably and consistently.
But you're not wrong that it's a barrier for entry. I see value in a TA-er working alongside a Developer to achieve a neat, reliable solution. There's a bit of potential for that in the near future here, so I am going to follow through with your suggestion at my end for sure.