bignimbus / extended-javascript-console Goto Github PK

Now that we are using several dependencies for building and testing the project, the readme should specify exactly which tools to use and how to use them.

console.expect methods only return booleans. These messages should be made more meaningful, descriptive, and (dare I say) pretty-looking.

Some test messages do not have a conditional for the not option.

As it stands, there are some issues with how the object diffs are handled. Instead of cloning the original object, the diff should be constructed only when the data differs from the original object.

I can see in background.html that there are some network errors for:

http://resources.crossrider.com/apps/68915/resources/meta/0

I guess it's related?

plugin info:

Version: 1.26.33
Updated: February 17, 2016
Size: 171KiB
Language: English (United States)

chrome version:

67.0.3396.62 (Official Build) (64-bit) (cohort: 67_win_62)

My implementation of .not in main.js may or may not be the best way to go about this. I could use another set of eyes.

Crossrider, the API used to make the xcon browser extension, is making a fresh XHR request on pageload. This can cause the extension to break on certain pages (#43) and degrade the UX. All future releases should hardcode the minified source code.

Proposing a new method that is similar to the non-standard console.assert().

The idea is to use syntax that resembles testing frameworks for quick, accurate testing using the console. The console output would be equally descriptive as .run() so that we're not just doing some fancy syntax that boils down to a vanilla true/false log statement.

var objOne = {
  "something": "something"
},
objTwo = {
  "something": "something else"
};
console.compare(obj1).expect({"something": "something"}); 
// PASSED: expected obj1 to equal {something: something}
console.compare(obj1, obj2).expect(true); // compares two blobs, returns true if they are identical
// FAILED: expected obj1 to equal obj2
// diff: (show the diff)
console.compare(obj1, obj2); // outputs a diff
// obj2 differs from obj1: (show the diff)

/* or */

console.expect(obj1.something).toEqual("something"); // true
// ape Jasmine or Mocha syntax

Some thoughts from experienced test-writers would be helpful.

There are new modules that do not have tests yet. We should fix this and update any legacy tests that are no longer useful.

Right now, xcon gracefully errors out when calling .diff or .isEqual on complex data models (call stack size issues, usually). Alternative ways to test these structures would be nice to have.

We need a unit test to make sure that the code instantiates an xcon object with xcon.out() and .run() functionality in case there is already a native instance of console.out or .run().

The condition module serves two different purposes currently: determining the type of the input and converting the input to a string depending on its type. We should consider splitting these two features into separate modules.

We should look at all of the xcon methods and see how they can be migrated into more testable modules.

When a message exceeds a certain number of characters, xcon should truncate the message and call console.log() on the output instead.

For example, if there were a deeply nested object that has lots of data, JSON.stringify() would produce an prohibitively long error message when calling .diff or .expect . Instead of showing the entire string, it would make sense to truncate the message and call .log() to show the object/array in a more legible format.

hi, i just installed this to chrome on my chromebook as an extenion from the chromestore, but when i try console.out('joe'); it says console.out is undefined. thanks

To encourage best practices, it would be nice to implement a githook that runs grunt jasmine as well as eslint rules. We should research and apply these in a way that makes sense for this project.

console.diff now outputs path:value strings instead of vanilla console logging the diffs. Screenshots and documentation should be updated.

.toContain, toBeNull, and .toBeTruthy need readme sections.

Currently the dev environment is not standardized. This ticket will be closed when a developer can pull a branch and get:

• a test spec runner (phantomJS? jasmine in the browser?)
• a package.json that only installs the stuff they need, configured properly

Test xcon in multiple browsers and address any compatibility issues

This feature needs thorough Readme documentation.

This will require all arguments to be passed as an array.

console.run(fn, args, context);

console.out('hello');
// string hello

should be

console.out('hello');
// string "hello"

This feature is already partially implemented. Update source, docs, and specs to ensure that console.run(obj) or console.run(string) etc... returns the actual value. This allows for logging without taking up multiple lines:

var a = console.run('a');
a === 'a'; // true

Current source code should be ported to AMD modules.

A tool such as almond.js or amdclean should be used to concatenate and port modules into a single file that can be run in a browser without a module loader.

Devs should be able to pass in an arbitrary amount of data into console.out a la console.log. opts will always be the last arg.

right now:

console.out('hello ', obj, opts); // will not function.  This should function.

In some field testing, I'm seeing TypeErrors in certain data models that contain circular references. This is probably something that could be caught and controlled in the condition module.

There is currently one xcon.spec file. We should have one spec file for each module so that the code is more thoroughly tested.

screenshots should be retaken.

Current screenshots in readme are out of date.

Capture new screenshots and update readme with them.

xcon should support Bower.

There are currently four methods possible in console.expect. There are additional methods that could be useful to developers. Those methods should be identified and developed.

Diffs could be very useful for finding differences in complex data sets.

var harry = {"mock": "yeah", "yeah": "yeah"},
lloyd = {"bird": "yeah", "yeah": "yeah"};
console.expect(harry).toEqual(lloyd);

This should return something like:

FAILED: expect object harry to equal object lloyd
object harry has unique data
  {"mock": "yeah"}
object lloyd has unique data
  {"bird": "yeah"}

This will prove to be a complex task. Care must be taken to build exact paths to the diff data so that it is useful to the developer.