So I have a bit of a conundrum, the job I will be going into I will be constructing an automation framework from scratch. They’ve never had any automation so it’ll be a completely fresh start.
I know they sit in a .Net/C# environment, however Im wondering how big of a deal it is to write the automation code in something more familiar (Such as JS/TS).
The reason I ask is two-part:
The framework I plan to use (Playwright) supports C#/.Net, but the docs are honestly pretty poor on it AND examples are very lacking. I also think it’s a bit more confusing to newer coders (I will be training manual tests on automation as well so keep in mind)
Secondly, I think if I am training manual testers…it’s probably going to be more focused at black box testing. So API testing/UI testing is more removed from backend code. (Maybe using Postman/Newman for API testing not sure yet).
Do you think this is a poor reason? Or should I just try and force it and use the backend language they use. I see benefits to it obviously…but I feel like also if I plan on de-coupling the testing I don’t see why it would matter?
There’s concern here about choosing the “right” tool.
The best answer I can provide is to take your top tools and do some timeboxed PoCs. Set very basic, high level goals and see how well you can meet those with different tools.
Is it fair to assume you are using playwright for UI driven tests? If so, any idea what the front end code is written in? It’s possible that using JS/TS won’t be that far removed from what they do for the front end code anyway.
For API testing, have you considered using restsharp?allows you to keep the api tests in the same language as is being used to develop the APIs that way.
Yes probably. From what i’ve read/research i’ve done it seems to be the best out there (Im used to Cypress fwiw).
for API testing I have considered restsharp, but i’ve read a lot of people said it’ s kinda deprecated/maybe has issues? I’ve seen people suggest to shy away from it (not sure why however)
What is the vision for the app? Is it a client-server or cloud/infra and database based app? Or Hybrid web-UI. I might look at tools that work well with what the app is moving towards, so JS/TS would be my choice if I were in that boat.
There are reasonable arguments about not needing it any more as .nets native httpclient can do it all, but at the same time, for me at least, I like it. It’s also well documented which makes learning it much easier for newcomers.
Picking a test tool is all about what’s right for the team, as long as it does what you need in the way you want, it doesn’t matter what the internet says.
Use the tool that will provide the best test repeatability and accomplish all (or most) of your test automation objectives.
Choose a language you already know or are going to be able to support and teach to others (assuming little to no developer support. If that’s not the case, choose a language everyone can tolerate that you like - it sounds like you’ll be in the automation code more than most others, so you may as well be productive).
Pick a tool that fits your current knowledge and allows you to bring on/create new automation engineers with low overhead (think: how good is the online training and documentation for this tool?)
Be sure to sell these factors as ways to increase productivity that management should begin to see almost immediately. This will help persuade them to let you make the decision that will affect you and your coworkers (again, assuming you need to convince them).
Welcome to the Club @boroop . 100% agree, great points in general. Do keep these ideas coming in, especially the part where the engineers must “sell” or present their idea, not just go ahead and do without getting buy-in from other leads. Even letting people believe they had a part in the tech stack choice helps get their support.
Whenever tool choice question come up. It’s often easier to over-think and over-consult. But the reason that slower approach works might be down to the way it give people time to talk about the future vision more clearly. So having microservices architecture and scale as big drivers of your choice will surface questions like, can we use this tool with j-meter/gatling to build new performance tests or really useful load tests for example, and so on. As usual be wary of one engineer pushing a new tool or language just because proficiency in that tool or language is something they want to add to their personal CV.