Testing in production a.k.a monitoring


    This project contains all core functionality related to the New Relic synthetics that are used as current monitoring strategy. It's based on "Scripted browser" monitor type. They provide and work on top of WebDriverJS. I personally prefer to spin up my local execution since there are some limitations like no control of the flow, DRY  (you get just a text area for your script) and remote execution.  But with little effort you can work-around all this.  

                                  

    Setup
    You will need to do the following steps:
  1. Go to this Python guide and follow the steps
  2. Go to this NodeJS guide and follow the steps
  3. Clone the VCS repo and make sure any sub-modules have also been cloned
  4. Open cmd and navigate to your project
  5. Run node your-file-name.js
    Use
    Ideally this will allow sharing and DRY code between the monitors. You can use the marked snippets with // ######## My Local code ####### in all places you need to. But be careful not no upload any code that is not needed in New Relic!
e.g.
fixture, setups, tear-down

    Fitness function


    Fitness function plays an important role in the stability and effectiveness of any test/monitor. It can greatly improve the pace of software testing strategy. To use it follow these steps:
1. open cmd
2. cd to the repo (location of fitness-function.ps1)
3. run this line
 powershell .\fitnese-function.ps1 -path C:\pathToMyTests\myTest.js

    This is what I've made up with PowerShell: 


    And this is what a simple monitor looks like:



    Since you already took all SaaS advantages of the NewRelic platform, let's talk about its inner ways of providing them to you. At first glance it appears that all you need to do is throw some JS code into the text area and the magic just happens. This is just one side of the coin. Simple and complex go hand in hand here.


                                   

    You'll get your WebDriverJS objects $browser and  $driver from nowhere  and rely that they are what you need. Same goes for the .waitForAndFindElement(element, timeout) rely which turns out that don't exist outside of the monitor scope (text area, snippet etc.). Like I already said DRY is a huge issue here. So your local .js monitor files need to be aligned with this. I've created my own objects from the Selenium ones and reused them to suit my case. First one was the  $browserObj which was inherited later from $browser via classical inheritance. I've also added the missing method .waitForAndFindElement and attached it to my final NewRelic clone of $browser.  Next major object is the elementMap responsible for keeping the web elements and their locators (you can think of it as mini Page object model). It would get a really nice JSON out of it, but with the current situation let's keep it simple. The intend of actionWrapper is to keep all shared functionality across the monitors, all you need is just copy-paste the attached to its .prototype functions. You can keep those in separate .js file (as reference). The last thing that's left to do is chain the JS promises and form your monitor script.



1 comment:

  1. You have provided valuable data for us. It is great and informative for everyone. Keep posting always about hire qa engineers. I am very thankful to you.

    ReplyDelete