Add PubWise Bid Simulator

[GLStephen]

Type of change

• [X ] New bidder adapter

Description of change

Addition of PubWise Bid Simulator Adapter. The Bid Simulator is part of the testing package we use internally for PubWise.io. We are making it publicly available because we feel the Prebid community will get some value from it.

• test parameters for validating bids

{
        bidderCode: 'pubwiseSim',
        bids: [
          {
            bidId: 'testId1',
            bidder: 'pubwiseSim',
            params: {
              site_id: 'test-test-test-test',
              height: '728',
              width: '90',
              cpm: 20,
              delay: 0,
            },
            sizes: [[160, 600]],
            placementCode: 'div-gpt-test-1'
          }
        ]
      }

• [email protected]
• [ x ] official adapter submission

Other information

[GLStephen]

I have resolved the conflict related to the list of active adapters.

[mkendall07]

@GLStephen
Could you explain the purpose of this? Just not sure is all.. thanks

[GLStephen]

@mkendall07 We use it, similar to an echo server, to perform automated testing in our test environment. It allows you to send "real" not code level mocked bid requests into your Prebid setup and test end-to-end configuration, analytics setup and DFP integration and timeout behavior. I thought it would be useful to the Prebid community in general.

I really appreciate the value of unit testing at a code level in Prebid.js, but often it is insufficient for some types of testing. For instance, if you want to verify interaction of DFP and non-header bidding line items you can either use a test tag from a demand partner, wait for a bid of some value to happen by, or you can use PubWise Sim.

In the end, PubWise Sim provides significantly more control over the response than a test tag does and lets you introduce latency, and other options such as mismatched sizes. In addition, you can set variable return pricing without having to twiddle an adunit ID (like a test tag likely would have you do) which lets you through code control testing with more ease.

Also, the resulting "creative" is a simple image, clearly marked as a test tag so there is no chance of confusion.

On an organizational basis, this would let a team integrate, test and verify a Prebid site integration without ever running demand partner tags. Reducing confusion, improper serving and providing more accuracy.

[GLStephen]

Documentation is here: prebid/prebid.github.io#241

[bretg]

@GLStephen - this is good background, and looks like a useful tool. I'd suggest adding some of the words from above into the prebid.github.io doc PR. Will make a specific suggestion over there.

[jaiminpanchal27]

@GLStephen I am getting 404 trying to hit your endpoint. Test page https://jsfiddle.net/61ak300m/

[GLStephen]

@jaiminpanchal27 endpoint is up now, sorry about that, it had not been made live on the production farm

[GLStephen]

@bretg updates have been made to the documentation piece

[jaiminpanchal27]

@GLStephen I checked this and it works fine. This is good testing utility but i don't think it should be developed as an adapter. Also no test related code should be inside ./src

[GLStephen]

@jaiminpanchal27 I understand your concern. It's one of those "isn't exactly like, but must behave like to properly test" sorts of things. In some ways, it is accurate that this is a test, but the current testing in ./test is more like unit tests, not outside in testing. This is more of a black box outside in interaction with controls vs. a whitebox unit test. Is there an alternate place for this sort of thing that can provide the same level of testing interaction, particularly pre-prod style integration testing which is the focus here?

The current testing options are great for Prebid at a code level, not necessarily at an integration level. They don't provide access to the DFP related items like Delivery Diagnostics when an error is encountered. At least part of the focus here is "A HB ad did not display. Why? Oh, we're running a standard lineitem still because we missed it while reconfiguring for Prebid". Or, "The line items for HB aren't active." Or "Our price priority lineitems should kick in at < X CPM, we need to verify that." All of this style of testing is in-browser integration testing that the mocha/jasmine/gulp tests don't provide.

[jaiminpanchal27]

@GLStephen Yes our integration level test is not upto the mark yet. We have tried this using nightwatch and browserstack. You can check this PR #982 for end to end testing.
Integration testing is also in discussion for Prebid 1.0. Add your thoughts here #891

[mkendall07]

@GLStephen
Appreciate the feedback on integration test with a focus on the publisher. I do believe we need this, but we don't want it as part of the codebase here. We are talking about building out a toolset to help with this but it's in the early stages.