Hi,
I am new to node.js and was previously using frisby and stumbled upon IcedFrisby from there.
I am trying to create API test Case where I want to use function to test value.In my case it is settings.search is a function but When I run the test I get Following error:
Uncaught Error: Invalid schema content: (settings.search)

For Following code

var frisby = require('icedfrisby');
 var Joi = require('joi');
 frisby.create('Test Response')
   .get('https://api.myjson.com/bins/rpay')
   .addHeader('User-Agent', 'frisbyJS Test')
   .expectJSONTypes('data.user.*', {
     id: Joi.number(),
     title: Joi.string(),
     'settings': {
       'vOrder': Joi.array(),
       'sState': Joi.array(),
       'search': function (val) {
         // Trying some function
         expect(val).to.be.a('array');
       },
       'visits': Joi.array()
     }
   })
   .toss();

Then I tried this syntax which frisby did not support

   .expectJSONTypes('data.user.*.settings', {
     'search': Joi.string()
   })

But If i use this syntax, My test is passed no matter what i write in it.mocha would say
1 passing (2s)
for example :

   .expectJSONTypes('data.user.*.settings', {
     'search': Joi.array(),
     'sadsa': Joi.array(),  //  random key  here
     'etetete': Joi.array() //  random key  here
   })

Mocha still says 1 passing (2s) which is wrong since I dont have sadsa and etetete keys.

Please help
1.How can I use function
1.How can I use nested array path like .expectJSONTypes('data.user.*.settings', {

MY SAMPLE JSON :

{
  "success": true,
  "data": {
    "user": [{
      "id": 27,
      "title": "ABC",
      "settings": {
        "vOrder": [0, 1, 2, 3, 4, 5, 6, 7],
        "search": [{
          "order": "id",
          "items": [{
            "np": "9",
            "value": "47"
          }]
        }],
        "sState": [{
          "name": "id",
          "visible": true
        }, {
          "name": "name",
          "visible": true
        }],
        "visits": 10
      }
    }]
  }
}

Hiya! Since we’ve a few of us are actively working on this and we’re progressing nicely to a 2.0 API, I’d like to make an effort to promote this library.

There are some more things we can do in terms of features and code, like return promises, be test-runner agnostic, test the plugin support, and tighten up the codebase. Though good features won’t promote the project on its own! Here are some good resources, with lots and lots of ideas:

• https://hacks.mozilla.org/2014/05/open-source-marketing-with-velocityjs/
• https://github.com/LisaDziuba/Marketing-for-Engineers
• https://github.com/rdp/open-source-how-to-popularize-your-project#links

Probably we'll want to plan most of this in conjunction with the 2.0 launch, though I thought we could get the ball rolling.

@Fishbowler Are you in?

Hi,

i have installed icedFrisby in a package npm with xunit-file and mocha.

The problem is that when i launch the test, the module joi which is installed in the module frisby cannot be found.

Here my package dependencies :

"dependencies": {
"icedfrisby": "^0.2.0",
"mocha": "^2.2.5",
"xunit-file": "0.0.6"
}

module.js:338
throw err;
^
Error: Cannot find module 'joi'
at Function.Module._resolveFilename (module.js:336:15)
at Function.Module._load (module.js:278:25)
at Module.require (module.js:365:17)
at require (module.js:384:17)

For information, i use a makeFile to launch test.

test:
@./node_modules/.bin/mocha -R xunit-file ./test/test.js
.PHONY: test

I use node version : v0.12.6.

(I've this problem on a specific machine, it works well on another machine).

Have you an idea about the issue?

Thanks in advance,

Headers added via addHeader or via request settings in config() are case-normalised.
Headers added via request params aren't.

That this is possible isn't actually documented - and it looks like all request params are supported.

This leads to a larger question:
Should we keep consistency (so in this case, move all normalisation to this block, perhaps), or do we respect the original intent of the developer?

I wanted to consider going one step further from #84 and moving expectJSONTypes into a plugin.

I'd prefer to have an unopinionated core, and let people use whatever schema validation library they'd like. Supporting more schema validation libraries probably means more plugins, rather than adding other schema validation integrations into core.

I'd also like to strengthen our budding plugin ecosystem. Having good examples of plugins, and people using them, helps do that.

@MarkHerhold it seems like you're a big Joi user, and that there probably are many icedfrisby users who are using it, so continuing to have smooth integration is important. The plugin would be pretty smooth, working just as today, though requiring a couple lines of code to construct the mixin. That can be moved into a utility package so it doesn't need to be repeated in every file.

The advantage would be fewer tests in core, slightly less code, and a shining example of what a schema-validation plugin should look like.

We could use lerna to manage development of both modules in a single repo. Honestly our plugin infrastructure is pretty stable and so is the expectJSONTypes code, so there may not be any need for coordinated development. It might be less work to develop it in its own repo.

Found as part of #94

• The not() function sets a mode, so applies to all expects in this create chain.
• Looking at usages, it's just pathMatch ones - expectJSON, expectJSONTypes, expectContainsJSON and expectJSONLength and won't apply to the other inbuilt ones, or to plugins that don't have explicit support.

This implementation needs replacing with an atomic and consistent approach.

Plugins are something else - perhaps some guidance in documentation would be enough.

We've got warnings in the repo for calling globalSetup() more than one, and that it "may cause unstable behavior".

I've run into that behaviour.

I've got multiple specs, each one requires one of two different setups (with/without JSON).
The before() of each spec runs the setup.
When run individually, each spec succeeds.
When run together with a mocha globbing selector, some specs don't run under the correct setup.

I've looked at the code and can't see an easy way to resolve this (e.g. some complex it-level config cloning). This feels like it could be a supported feature. I've got microservice API checks all bundled together rather than creating 2x the repos.

I couldn't write a node wrapper program that exec'd each spec in isolation, but is that dirtier than the problem?

Hi there,

first off, many thanks for porting frisby to mocha. This is really a timesaver. 🥇

Now it would be even more awesome if before(), after() and finally() also supported async functionality, e.g. like this:

.before(function(done) {
    // ...
    server.listen(done);
})
.post(...)
.expect(...)
.finally(function(done) {
    // ...
    server.close(done);
});

Would that be something you would accept as a PR? Thanks!

Version 3.4.0 of mocha just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As mocha is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

When trying to send a multipart request using the following parameters: { form: true }, it will throw an error in the underlying request module.
However, it will work properly if you use { form: {} }.
This is because when you construct the underlying request, you assign to the form property the true value and the request module does not like that.

await icedFrisby.create('Upload file - ${fileName}').post(url, { data: { value: content, options: { filename: fileName }}}, { form: true }).expectStatus(200).run();

Error: MultipartParser.end(): stream ended unexpectedly: state = HEADER_FIELD at MultipartParser.end (node_modules\\formidable\\lib\\multipart_parser.js:326:12)

If needed I can provide a repo to reproduce the issue.

There are a variety of nock'd domains.
When HTTP_PROXY is set to debug the real httpbin tests, it takes all nock traffic too, and requires a lot of configuration of NO_PROXY (or just some faith in the tests that don't complete) that things are working.

Move all nock'd domains to a single host for easier configuration in a development environment.

Upgrading to lodash 4 branch results in many broken unit tests. Need to track down which functions are causing issues (merge, cloneDeep, extend, etc...). Refactor icedfrisby.js to utilize lodash 4 with minimal changes to unit tests.

The less writing we have to do from a test perspective the better. In many cases I find these two items are the most repeated portions of my test code. Long story short I think both of these items could be added to the global config and get overridden when specified by the user.

• no global default specified, default functionality (current)
• global default specified, values are set globally for each test
  • user can override global as needed

Seeing ~all builds erroring with messages about nock, and some spurious response codes or 599s from httpbin. See Travis - not all builds fail the same tests in the same node versions, even when just rerun with no code changes.

I span up a branch that uses httpbin in a docker container, using the same version of the code that's live, and it's looking fine & healthy.

This looks like it could be a nock bug, a nock race condition, or a nock misuse by us. The second error here doesn't use nock, so looking likely that we've got a nock problem somewhere within our tests. I tried updating nock, but it hasn't helped.

  1) test with httpbin for valid basic auth
       
	[ GET http://httpbin.org/basic-auth/frisby/passwd ]:
      AssertionError: expected 599 to equal 200
      + expected - actual
      -599
      +200
      
      at _expect (lib/icedfrisby.js:439:45)
      at Frisby._invokeExpects (lib/icedfrisby.js:1266:26)
      at start (lib/icedfrisby.js:1249:12)
      at Request.runCallback [as _callback] (lib/icedfrisby.js:1136:16)
      at self.callback (node_modules/request/request.js:186:22)
      at Request.onRequestError (node_modules/request/request.js:878:8)
      at ErroringClientRequest.<anonymous> (node_modules/nock/lib/intercept.js:231:10)
      at process._tickCallback (internal/process/next_tick.js:61:11)
  2) should send all headers when you bootstrap them with parameters
       
	[ GET /headers ]:
     Error: Error parsing JSON string: Unexpected token I in JSON at position 1
	Given: [IcedFrisby] Destination URL may be down or URL is invalid, NetConnectNotAllowedError: Nock: Not allow net connect for "httpbin.org:443/headers"
      at _jsonParse (lib/icedfrisby.js:61:11)
      at _expect (lib/icedfrisby.js:610:19)
      at Frisby._invokeExpects (lib/icedfrisby.js:1266:26)
      at start (lib/icedfrisby.js:1249:12)
      at Request.runCallback [as _callback] (lib/icedfrisby.js:1136:16)
      at self.callback (node_modules/request/request.js:186:22)
      at Request.onRequestError (node_modules/request/request.js:878:8)
      at ErroringClientRequest.<anonymous> (node_modules/nock/lib/intercept.js:231:10)
      at process._tickCallback (internal/process/next_tick.js:61:11)

We could:

• Investigate what's broken
• Switch to using Docker permanently

Gut feel is to do both, but would appreciate some input.

When receiving multiple headers with the same name (e.g. Set-Cookie) you can't assert using expectHeaderContains or expectHeaderToMatch

Fixed in PR #73

Since we moved the repo to an org, coveralls won't display detailed code coverage.
https://coveralls.io/builds/13811290/source?filename=lib%2Ficedfrisby.js

I've got some WIP on fixing up some quick wins on missing coverage, so gimme a nudge when this is fixed. V low priority, obvs.

Running npm warns the user "[email protected] license should be a valid SPDX license expression".

• add jsdocs to current codebase
• generate documentation at build time
• publish documentation to github pages (automated)

e.g. https://circleci.com/gh/IcedFrisby/IcedFrisby/1294

calling Frisby.timeout(5000) to set a timeout is not working for me. The default of 2000 always happens.

Its possible to pass in a timeout to Mocha via file or the command line but I'd prefer to just set it here if possible.

If you click the package dependencies badge on the readme it links to an invalid report.

Not sure what the mechanism is for gemnasium.com but it appears to be displaying results for packages that are no longer listed in package.json. If I can do anything to help please let me know.

I wanted to suggest we remove IcedFrisby repository from the Github repository graph. Which is to say, classify it as a standalone repository instead of a fork.

This is a good thing because Github treats forks differently: they don't come up in searches, they are not internally searchable, they have worse SEO. Initially we may take a small hit because I think our downstream forks will be disconnected, though overall I think this is worth it. It may help people find the project!

While this project is technically a fork of frisby, it's no longer really useful to think of it that way, at least in Github's sense of a fork.

@MarkHerhold if you agree, you'd need to contact Github by email to request this.

Version 3.5.3 of mocha just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As mocha is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Would a dedicated gitter help IcedFrisby?
I already help a few others via other channels, and it'd enable discussion around #103.

This fails:

describe('Testing Overrides',function(){
    it('should expect modified requests to have been modified', function(){
        frisby.create('Add dummy header')
            .get('http://httpbin.org/get')
            .setResponseHeader('lol','rofl')
            .expectHeader('lol','rofl')
        .toss()
    })
})

The setResponseHeader and other setResponseX methods are Frisby legacy that existed to enable unit tests of the pathMatcher, but aren't used any more. Fix or remove?

Version 2.13.1 of coveralls just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As coveralls is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

As I mentioned in #26 I'm working on a POC of some tests for https://shields.io/ (see badges/shields#927).

I'd like to add plugins for:

• A custom assertion
• Setting up and cleaning up mock requests using nock
  • Probably that will look like this: .intercept(nock => nock(...).get(...))

I noticed custom plugins were mentioned in the readme. Any thoughts on how the inheritance would be implemented, or libraries with good patterns to follow? Mixins could be a way to do it.

The nock plugin would also need a before() function to register callbacks, as a counterpart to after(), which seems straightforward enough.

Version 7.2.0 of check-types just got published.

This version is covered by your current version range and after updating it in your project the build failed.

check-types is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you it’s very likely also breaking them.
I recommend you give this issue a very high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Version 10 of Node.js (code name Dubnium) has been released! 🎊

To see what happens to your code in Node.js 10, Greenkeeper has created a branch with the following changes:

• Added the new Node.js version to your .travis.yml
• The new Node.js version is in-range for the engines in 1 of your package.json files, so that was left alone

If you’re interested in upgrading this repo to Node.js 10, you can open a PR with these changes. Please note that this issue is just intended as a friendly reminder and the PR as a possible starting point for getting your code running on Node.js 10.

Your Greenkeeper Bot 🌴

Joi is listed as a dependency of IcedFrisby. The install instructions suggest installing it separately, which makes sense since it needs to be required directly in the user's code.

It wouldn't be good to have multiple versions of Joi installed. So, the user could keep their joi version in sync with the version required by IcedFrisby. That could be fussy though.

Another option is to make it a peer dependency, meaning it has to be required separately, and npm will complain loudly when it is not installed. I've used this a lot with good success, and it tends to simplify upgrades quite a bit.

We could consider doing the same with chai.

Mocha is already a peer dependency.

After #257 behavior has changed when network connections are disabled. It's emitting this error:

     NetConnectNotAllowedError: Nock: Disallowed net connect for "example.com:80/test"
      at /Users/pnm/code/icedfrisby-nock/node_modules/nock/lib/intercept.js:449:23
      at Object.module.request (node_modules/nock/lib/common.js:99:14)
      at Request.start (node_modules/request/request.js:751:32)
      at Request.end (node_modules/request/request.js:1511:10)
      at end (node_modules/request/request.js:564:14)
      at Immediate.<anonymous> (node_modules/request/request.js:578:7)

Where before the 599 error code was being returned.

I'm not sure if this was intended; needs some more investigation.

See paulmelnikow/icedfrisby-nock#106.

I've been able to create two scenarios.
In both, the call to post calls _request and this.current.outgoing is made as a copy of some defaults, this.current.request, and any parameters passed in.

In one, no parameters are passed in, and every time addHeader is called, the code appends to this.current.request.headers and by some witchcraft this.current.outgoing.headers stays perfectly in sync at runtime.

In the other, parameters are passed in, and every time addHeader is called, the new header goes to this.current.request.headers but never pushed to outgoing and never used in the resulting request.

I'd love to understand what's happening here, but in the meantime, I also propose that we modify addHeader to use current.outgoing to resolve the problem.

This all came about as I looked to modify my repo of tests to work around #93

Gonna quote @chris48s from dszakallas/joi-extension-semver#12.

As noted in hapijs/joi#2037

The entire extension system has been replaced with a new framework that is now at the core of the entire type system. Every built-in type is just an extension of the base type. Everything the built-in types can do is now available to extensions.

The retry and wait functionality are not covered by tests. Without coverage, we risk breaking them during refactors.

Hello,

The Readme claims the following:

.afterJSON(user => {
  // You can use any normal assertions here
  expect(1 + 1).to.equal(2)
})

However, this doesn't seem to be the case. I wrote this simple test:

const { expect } = require('chai')
const frisby =  require('icedfrisby')

frisby
  .create('example test')
  .get('https://google.com')
  .expectStatus(200)
  .afterJSON(json => {
    expect(1 + 1).to.equal(999999)
  })
  .after(() => {
    expect(true).to.be.false
  })
  .toss()

The test passes, neither of the expectations in the callbacks fail. Am I missing something here?

Thanks in advance.

Cheers,

Pyves

This would be helpful for implementing paulmelnikow/icedfrisby-nock#101, which in turn is for badges/shields#2195, where we wanted to configure tests so the intercept()ed tests were skipped and the others were run.

When calling expectJSON with the optional path argument, you can't specify a string as the jsonTest parameter.

Example response:

{
  "key1": {
    "key2": "value1"
  },
  "key3": "value2"
}

Calling expectJSON('key1.key2', 'value1'), is not possible, as the second argument value1 is not an object.

expectContainsJSON could be used as an alternative, however, its syntax isn't as concise especially with more complex JSON structures, and the error messages are much more vague as we're checking that a structure contains another. It would be nice to have something that gets to the point by strictly comparing a string at a given path with an expected string.

Support for this could either be implemented in expectJSON itself or as a separate helper function.

See the discussions here for more context.

Cheers,

Pyves

Lots of APIs sit behind cookie driven, web-based authentication.
Either implement a cookie jar implementation, or piggy-back on request's jar()

Right now IcedFrisby only works with Mocha. Tests must be enqueued by IcedFrisby via .toss(). While it's possible to use our setup code to run hooks at various parts of the test lifecycle, it is not possible to return control back to the calling function when the test has finished.

Promise support would solve that.

It's been in our roadmap for a long time. Here are some links to related issues in Frisby (which now has this support).

Support chained tests/promises. Related: #127, #154, #200

Promise support would make it possible to use IcedFrisby within an it(), makes it possible to use it within other test runners, and possible to use without magic.

Promises would also make testing easier. There are currently a bunch of tests which say "How can I assert that this function has been called"? Getting control back after the test ran would make this easier.

Since we've just dropped Node 6 support in #176 we can write this all using async/await which should also make the code much nicer to read.

I hardly want to bikeshed, though I wonder if we should drop semicolons. I've stopped using them in my own projects after being solidly in the Crockford camp for years. These two sources, along with the fabulous linters we have today, have convinced me:

• https://www.youtube.com/watch?v=Qlr-FGbhKaI
• http://blog.izs.me/post/2353458699/an-open-letter-to-javascript-leaders-regarding

IcedFrisby syntax in particular (and function chaining in general) looks nicer without semicolons, and is also much easier to modify. If I chain on more assertions, or remove some, I don't have to worry about placing the semicolon in the right place. If I add a callback with an arrow function I don't need to place the fussy semicolon inside it.

Where this would help most, internally, is the tests, where I've often run into this pain point.

Every line of icedfrisby.js is touched in #46, so git blame is useless right now. If we were to make the change, right now wouldn't be a bad time. When we do it on the other files, I'd want to fix the indentation at the same time.

Again, really don't want to bikeshed. This is about the least important thing I can think of.

Source

The last round of documentation added some reverse engineered params that are explicitly used.
In fact, we've got some of our own, plus everything that request supports.

I've got a need to run some of my tests, (e.g. ones safe to run against Live)
Mocha docs imply I can do this with --grep [regex] or --fgrep [string]

But it doesn't work with IcedFrisby.

Here's a trivial example: https://github.com/Fishbowler/playground-icedfrisby/blob/master/specs/wikimedia/wiktionary_spec.js

From the root of this repo, the following things happen:

mocha '**/*_spec.js' --fgrep '@important'
Prints the first and third describe/it but runs no tests. This is my real use case.

mocha '**/*_spec.js' --fgrep 'purple'
0 tests found

mocha '**/*_spec.js' --fgrep 'important'
Prints the first and third describe/it, but runs the third one

Seems you need the word in both the it(...) and the frisby.create(...) for it to actually run the test.

I'd rewrite all of the tests to work like the unit tests, using frisby.create(this.test.title), but that triggers a nullref - test is undefined.

I've looked through the source and can't see a cause, but also can't see a workaround beyond manually renaming All The Things. Any ideas?

Hi all,
I'm trying for few days to use IcedFrisby framework, I like it a lot.
But there is a problem where i get 599 response.

AssertionError: expected 599 to equal 401
   + expected - actual
      -599
      +401 

Is it something wrong with my code?
I'm trying same request with postman and it is working properly.

const  frisby = require('icedfrisby')  // Get IcedFrisby with npm install icedfrisby.
const Joi = require('joi') // Get Joi with npm install joi.

const URL = 'http://dev-cmpapi.greatplacetowork.com'

frisby.globalSetup({ // globalSetup is for ALL requests.
  request: {
    headers: {
      json: true,
      inspectOnFailure: true
    }
  }
})

frisby.create('prvi test')
  .get(URL + '/api/Client/details')
  .expectStatus(401)
  .toss()

package json

"dependencies": {
    "mocha": "^3.4.2",
    "icedfrisby": "^1.2",
    "joi": "^10.6"
  },

Thanks a lot in advance

If you guys need any more info feel free to ask.

I've got a need for XML support in IcedFrisby for post body and assertions.
Doesn't look too difficult using something like xml2js.
Would you accept a PR for this, or would you prefer it implemented in a plugin?

Found as part of #106

frisby.create(this.test.title)
      .baseUri('http://httpbin.org')
      .get('/headers', {headers:{'a':'1', 'b':'1'}})
      .addHeader('a','2')
.toss()

In this example, the request is send with a=1. As with config(), params should be overridden by subsequent explicit request options.