Power Hour - Dive into Browser Developer Tools with Alan Richardson and Viv Richards

Hey guys, thank you for your time. You’ve mentioned manipulating CSS - can you elaborate on using dev tools to do this? And provide an example of how you’ve done that? Many thanks,

Yeah the ‘live’ facility on the selenium grid tools might help as well - Saucelabs have a ‘live’ plan, and I think some of other grid system do as well.

Agreed - I read that and follow on twitter as well.

1 Like

Hello, for me currently Dev Tools offers me the tools I believe I need. I’m guessing over the next few months or year though they will release even more fantastic tools which I didn’t know I needed :slight_smile:

I find that if DevTools doesn’t offer something I think I need I’ll either try to get an extension for Chrome or failing that, if I cannot find an extension for what I need I’d attempt to make my own or help others develop one.

Thank you :slight_smile: … added padding because post must be 20 characters…

2 Likes

Hi Adam,

To answer that I’ll have to limit functionality to ‘what would I expect to be implemented in a browser’. Because I never expected Firefox to implement amending HTTP messages in a browser and if I don’t limit it, I could be listing stuff all day :slight_smile:

  • HTML, CSS and JavaScript validation could be useful (because the browser has a habit of ‘fixing’ HTML, and ignoring CSS errors)

  • I find the memory monitoring and performance tools a bit of a hassle to use, they could be simpler. I’d rather see it real time than creating profiles.

Oh and on that note - Alan has created a cool extension here which I contribute to which you may wish to check out https://github.com/eviltester/usefuljssnippetextension/

1 Like

… oh… and…

  • Having the tabs viewable at the same time e.g. seeing traffic while browsing DOM

  • JavaScript event hook indicators on the page so I can see what has JavaScript events attached without having to hunt through the DOM view

  • Breakpoints on cookie changes

  • Custom alerts on certain headers

I expect over time some of this will make its way in over time, and some of these are probably available as Chrome plugins if I really wanted them.

Hi Elizabeth,

I listed the addons that I use further up. I haven’t tried Lighthouse (I’ll have to research it, thanks for mentioning it).

The plugins are easier to use the less JavaScript heavy the app is. With a JavaScript heavy app, because the DOM is changing so much, I have to remember to use the tools more often.

As I mentioned above, whilst I do use some extensions for non-test related stuff, I think the majority of add-ons/extensions I use are for accessibility testing.

  • Lighthouse - I like using this built in audit tool to get quick feedback on potential accessibility issues as an initial check.
  • aXe - I like using this add-on to get further feedback on potential accessibility issues
  • WAVE - I tend to use this extension to compare the findings within aXe to quickly check some of the accessibility issues the add-ons believe they have found
  • Chrome Lens - this is really cool extension for checking to see how people with visual impairments view your site. For example if you have a web form and you rely on colours to indicate errors and do not also display a message with an error this tool would help you identify an issue for a person with a visual impairment. It also offers a built in tool to check how your page flows to ensure it tabs for example in a logical flow across the page.

Hi Penny,

I prefer CSS locators because they work in the find functionality of all browser DOM views. Xpath, only works in firefox (I think)

I only tend to use XPath for extreme situations like navigating back up the tree i.e. finding a child and then traversing up to the parent.

And CSS locators tend to be understood by the front end programmers, and no-one seems to really understand XPath anymore unless you have some XSLT technology in your app.

Hi Penny, I tend to never use XPath but similarly to Alan I could be tempted to use it in extreme cases for example where I couldn’t use an ID or CSS locator.

Wherever possible I’d always try to work within my team to make the UI easier to test by getting unique selectors where possible implemented to help with the teams automation efforts.

Like Alan, I prefer CSS locators. I prefer them because I find they help me write cleaner code when attempting to implement and maintain tests where as XPath can become quite a pain not only in initially attempting to locate the element you wish to interact with but also to maintain that test should the UI change.

Hi Penny, thanks for multiple questions…

I rely on the official developer site:

But I’m also trying to use a feature that Viv showed me, which is the release notes link in the dev tools itself. The help menu in the dev tools has links to “documentation” which is the link above and the release notes for the current version.

And I follow the developer tool twitter accounts.

You can see the calls that the browser makes to a REST API via Ajax. I’ve used this to reverse engineer APIs for applications to help me automate my marketing work. These APIs are often not public but are usually stable enough for the type of work I do.

I normally use a Proxy tool for this and make API calls from Insomnia or Postman through the proxy to capture the requests.

I also feed my mobile device through the proxy to see what traffic is being sent over HTTP.

I normally rely on a proxy for API testing. Then I can fuzz the requests.

1 Like

Hi James,

The CSS view are on the right of the DOM view or the Inspect view. And I find it useful to switch on and off different CSS styles.

And I can amend them which is useful when raising a defect and suggesting a potential fix.

It also has the ability in the dev tools to force element state - e.g. toggle hover , active focus etc. Which I find useful for testing and taking screenshots when there is a problem.

And using the dev tools to block requests to prevent CSS being loaded can be useful to see just how much work the CSS is doing.

I literally have all of these installed and can second this recommendation :+1:

3 Likes

As Alan mentioned, I tend to also rely on the official developer site.

I find sometimes though as with anything just relying on reading documentation to learn can be very dry.

I mentioned in an earlier response above a gentleman called Umar Hansa (Dev Tips - Developer Tips by Umar Hansa) .I like to follow him as he messages out often about cool new tools being released within Chrome DevTools. I find when I see some of the cool new tools which are getting released within Chrome I start to gain an understanding of how they could be of use to my day to day activities, that then gives me a starting point to know what to dig deeper for within the official documentation.

So many extensions I haven’t used :slight_smile: So much more to learn and experiment with :slight_smile: The only one I’ve tried there was BugMagnet, I also found the source for that useful when I was writing my own Chrome extensions.

I’m looking forward to the LTG workshop so that Viv can show me how to use the overrides properly - I’ve never managed to get that working and simulate it with proxy tools.

I also need to try the Coverage tool. I’ve never noticed that or used it :slight_smile: But I need it.

1 Like

:slight_smile: I know right, I use just a handful currently but there are so many great add-ons and extensions out there. I’m currently really liking the ‘Page Monitor’ extension you showed me.

Like you I also used the ‘Bug Magnet’ extension to get an idea how to get started when I tried to dive in to extension creation a year or so back - it’s a fantastic extension.