New answers tagged

4

As a general principle, I'd follow a relatively simple approach: YAGNI (You ain't gonna need it) - don't code something until you need to automate it. DRY (Don't repeat yourself) - if you find yourself repeating code, extract the repetitive code into a helper method and call it with the appropriate parameters. Generally speaking, when I'm starting a new ...


1

For starters, it's good to remember that There are good practices in context, but there are no best practices But I've recently written a blog post on a coding kata for the famous Login Page, showing an approach that may help you to create easier to maintain page object structure. You check it out step-by-step of the refactoring process here. If you want ...


0

I had difficulty when deciding how far down to abstract things and when to make "helper" public methods in the page objects. Yup, the balance is hard to achieve. One approach I use is to consider 'levels of abstraction' as a guide. For instance if I have code that completes a form... that uses code that logs in... that uses a method to extract the ...


2

I don't have one advice fits all kind of answer (which is fairly impossible anyway), but just a few observations based on your question: You seem to complicate things too much, focus on actually checking the application, instead of on how and if you should create properties private and have getters and setters I think one of the benefit of JS for test ...


0

Here is what I did at Microsoft, not saying it's right just what I know. We saved secrets to the Key Vault. For local host we had to install a PEM file and set our environment variable to the SHA of the signature. There was a Setup step that checked if the PEM env var was set to use that to retrieve and set the secrets. That allowed access to the Key Vault. ...


Top 50 recent answers are included