Dealing with: "reinventing the automation wheel"

Got a situation where I have RF working great on my project but another (old-skool) team on another project has decided to essentially develop from scratch their own automation test files using C# which looks to me like pages and pages of mangled C# code which only the person who wrote it can fathom, they also have to be triggered manually rather than after build deployed via CI, and then on top of that they want to get a web dev in to design a front end for the reports so they make sense :joy:

I’ve now got to fight my corner not to use this pile of junk, wondered if anyone else had similar situation. I suppose the big plus for them is it all integrates with VS.

1 Like

I’ve never fought this fight, not sure on the best approach.

perhaps present your main robot file and it’s report to the “decision maker” saying this is what you have working now out of the box on a fully supported solution with no internal developer needed, then suggest the alternate solution be presented either now or “when it’s ready” (chirp chirp chirp)

You can use the already integrated with CI as a clincher, but that actually be the point that sways a dev manager (nightly build finishes = get test report)

Really it depends on the role of the “decision maker”, in this case the less they can code the stronger your case. But it may help to get a business rep (SME) in to be asked if they can understand the test cases (after all the test cases are meant to give them confidence in the application, if they can’t understand what’s being tested how confident can they be?)

Hopefully something here will help you make your arguments.


To add on to damies13/Dave’s suggestions:

How are your current RF tests written? It may be good to present & compare to the mangled C# code, with the assistance of the business rep review. May be bonus if the RF tests were BDD, or well written English readable tests.

Another case/alternative you can suggest is that the mangled C# code can be adapted to work within the RF framework as well with or without developer assistance, depending on your team’s skill, and thus minimal coding or migration efforts. Instead of VS/C# being the test execution framework, RF can drive the tests, with test cases written in the format you currently do, and the core critical code in C# can be reworked or ported to a .NET (test) library as keywords to execute, and the RF test cases simply call those C# keywords instead of the whole test written in C#. The .NET library would integrate with RF either with the nrobotremote .NET remote server interface for RF or via IronPython to execute RF. This option can be a win-win opportunity, with that other team being able to keep the core test interaction logic in C# and with their dev codebase, while the test team can interface to it and write tests using the RF, and benefit from the RF ecosystem - the CI integration, the reports, etc.

1 Like

You could also ask them to make an example implementation of one of your critical test suites to ensure their solution is actually capable of doing what is needed for your product / team. If not, kindly ask them when their framework will be capable of doing what needs to be done.

I would not consider IronPython myself, there’s an alpha release for Python 3.4 available since April, but 3.4 is pretty much deprecated…anything under 3.6 is really too old to adapt at this time.