aurelia-testing - npm Package Compare versions

Comparing version 1.0.0-beta.4.0.0 to 1.0.0

bower.json

 {
   "name": "aurelia-testing",
-  "version": "1.0.0-beta.4.0.0",
+  "version": "1.0.0",
   "description": "A collection of helpers for testing Aurelia apps and components.",
@@ -5,0 +5,0 @@ "keywords": [

dist/amd/wait.js

@@ -38,3 +38,3 @@ var __assign = (this && this.__assign) || Object.assign || function(t) {
                 timedOut = true;
-                rj(options.present ? 'Element not found' : 'Element not removed');
+                rj(new Error(options.present ? 'Element not found' : 'Element not removed'));
             }, options.timeout); }),
@@ -41,0 +41,0 @@ wait()

dist/commonjs/wait.js

@@ -37,3 +37,3 @@ "use strict";
             timedOut = true;
-            rj(options.present ? 'Element not found' : 'Element not removed');
+            rj(new Error(options.present ? 'Element not found' : 'Element not removed'));
         }, options.timeout); }),
@@ -40,0 +40,0 @@ wait()

dist/es2015/wait.js

@@ -26,3 +26,3 @@ /**
             timedOut = true;
-            rj(options.present ? 'Element not found' : 'Element not removed');
+            rj(new Error(options.present ? 'Element not found' : 'Element not removed'));
         }, options.timeout)),
@@ -29,0 +29,0 @@ wait()

dist/es2017/wait.js

@@ -26,3 +26,3 @@ /**
             timedOut = true;
-            rj(options.present ? 'Element not found' : 'Element not removed');
+            rj(new Error(options.present ? 'Element not found' : 'Element not removed'));
         }, options.timeout)),
@@ -29,0 +29,0 @@ wait()

dist/native-modules/wait.js

@@ -35,3 +35,3 @@ var __assign = (this && this.__assign) || Object.assign || function(t) {
             timedOut = true;
-            rj(options.present ? 'Element not found' : 'Element not removed');
+            rj(new Error(options.present ? 'Element not found' : 'Element not removed'));
         }, options.timeout); }),
@@ -38,0 +38,0 @@ wait()

dist/system/wait.js

@@ -38,3 +38,3 @@ System.register([], function (exports_1, context_1) {
                 timedOut = true;
-                rj(options.present ? 'Element not found' : 'Element not removed');
+                rj(new Error(options.present ? 'Element not found' : 'Element not removed'));
             }, options.timeout); }),
@@ -41,0 +41,0 @@ wait()

doc/article/en-US/end-to-end-testing.md

 ---
-{
-  "name": "End to End Testing",
-  "culture": "en-US",
-  "description": "Testing front-end applications has become an important task for today's developers. Not only do you want to ensure that your application's internal code operates correctly, but you also want to validate the in-browser behavior. This article will show you how to achieve this by combining Aurelia and Protractor.",
-  "engines" : { "aurelia-doc" : "^1.0.0" },
-  "author": {
-    "name": "Vildan Softic",
-    "url": "https://github.com/zewa666"
-  },
-  "contributors": [],
-  "translators": [],
-  "keywords": ["Testing", "E2E", "Protractor"]
-}
+name: End to End Testing
+description: Testing front-end applications has become an important task for today's developers. Not only do you want to ensure that your application's internal code operates correctly, but you also want to validate the in-browser behavior. This article will show you how to achieve this by combining Aurelia and Protractor.
+author: Vildan Softic (https://github.com/zewa666)
 ---
-## [What is E2E testing?](aurelia-doc://section/1/version/1.0.0)
+## What is E2E testing?
 
@@ -22,3 +12,3 @@ End-To-End (E2E) testing is all about testing your application against specific _scenarios_. From a requirements-engineering-perspective you'd call those _User Stories_. Essentially, these stories describe a series of actions a user performs to achieve a certain goal. So by assembling a bunch of these - referred to as a _test suite_ - you are able to verify that your web app acts as expected. The key to success, of course, lies in the amount and quality of tests written.
 
-## [How are E2E tests different?](aurelia-doc://section/2/version/1.0.0)
+## How are E2E tests different?
 
@@ -33,3 +23,3 @@ One of the key differences when working with E2E tests is that all of your work is located in the browser, which naturally leads to writing a lot of _asynchronous code_. It doesn't matter whether you request a DOM Element, send some fake keystrokes or trigger a click, each of these actions needs to be automatically translated to understandable instructions and sent to the browser under test. So working with `Promises` becomes a major enabler when keeping track of deferred executions and responses.
 
-## [Protractor](aurelia-doc://section/3/version/1.0.0)
+## Protractor
 
@@ -49,3 +39,3 @@ Although the previous section may sound depressing, there is hope for developers in [Protractor](http://angular.github.io/protractor/#/), an End-To-End testing framework. Under the hood it's actually a Node.js application, which supports a wide variety of assertion/test libraries like [Jasmine](http://jasmine.github.io/), [Mocha](http://mochajs.org/) or [Cucumber](https://github.com/cucumber/cucumber-js).
 
-## [A Basic Example](aurelia-doc://section/4/version/1.0.0)
+## A Basic Example
 
@@ -83,3 +73,3 @@ To get a basic idea of how this works, take a look at the following example.
 
-## [Accessing DOM Elements](aurelia-doc://section/5/version/1.0.0)
+## Accessing DOM Elements
 
@@ -113,3 +103,3 @@ Great! So we know how to load a page. But how do we find DOM Elements and see whether they are rendered properly? Protractor provides the global object `element`, an `ElementFinder`, which offers a *locator factory* `by` used to define a way to search for elements. Let's take a look at the following example.
 
-## [Interacting with Forms](aurelia-doc://section/6/version/1.0.0)
+## Interacting with Forms
 
@@ -138,3 +128,3 @@ Now we know how to work with general elements, but what about inputs? Wouldn't it be nice to fake data entries in order to verify the logic of a form? To do so, let's look at the next example. Our test will navigate to the Google homepage, search for a specific keyword, trigger the search and expect to see an element containing the given value.
 
-## [Protractor and Aurelia](aurelia-doc://section/7/version/1.0.0)
+## Protractor and Aurelia
 
@@ -188,3 +178,3 @@ In order to work with Protractor, there is a little configuration that is necessary. This is done in a configuration file, e.g. protractor.conf.js, which sets up the basic information for Protractor so it can find our test files, start the standalone Selenium server and wire up the `JasmineOptions` for the console output. The Aurelia [Skeleton Navigation App](https://github.com/aurelia/skeleton-navigation) thankfully already shares a pre-configured setup. Let's take a look at it.
 
-## [Testing the Aurelia Skeleton Navigation App](aurelia-doc://section/8/version/1.0.0)
+## Testing the Aurelia Skeleton Navigation App
 
@@ -209,3 +199,3 @@ Besides having the configuration file set up, the Skeleton Navigation App also defines a set of demo tests to help you get started with testing your own page. First you'd need to download the App directly from our [Github-Repo](https://github.com/aurelia/skeleton-navigation) and follow the installation instructions. Afterwards, in order to start E2E testing, simply open up a console and run the following command to start up the built-in web server:
 
-## [Page Objects](aurelia-doc://section/9/version/1.0.0)
+## Page Objects
 
@@ -272,3 +262,3 @@ To conclude this article we're going to quickly look at how to structure tests. We organize our test methods using a pattern called _Page Objects_ (POs). What this means is that you try to group information about _how_ you access parts of the application into a separate class. This makes it simple to access specific elements multiple times. Now instead of repeating the `element.by.xxx` code over and over across multiple tests, we unify the access, making it easier to maintain and modify.
 
-## [Test Specification](aurelia-doc://section/10/version/1.0.0)
+## Test Specification
 
@@ -323,4 +313,4 @@ The previously defined page objects can now be imported into our test specification by leveraging the ES6 `import` syntax. Using `beforeEach` we can instantiate the POs, navigate to the Web app and wait for the previously mentioned `aurelia-composed` event to start testing.
 
-## [Summary](aurelia-doc://section/11/version/1.0.0)
+## Summary
 
 We hope you enjoyed this introduction to E2E Testing with Protractor and the Aurelia Framework. Time to start writing some tests!

doc/article/en-US/testing-components.md

 ---
-{
-  "name": "Testing Components",
-  "culture": "en-US",
-  "description": "An overview of how to unit test Custom Elements and Custom Attributes.",
-  "engines" : { "aurelia-doc" : "^1.0.0" },
-  "author": {
-  	"name": "Martin Gustafsson",
-  	"url": "http://github.com/martingust"
-  },
-  "contributors": [],
-  "translators": [],
-  "keywords": ["JavaScript", "Unit Testing", "Custom Elements", "Custom Attributes"]
-}
+name: Testing Components
+description: An overview of how to unit test Custom Elements and Custom Attributes.
+author: Martin Gustafsson (http://github.com/martingust)
 ---
-## [Introduction](aurelia-doc://section/1/version/1.0.0)
+## Introduction
 
 With the Component Tester you can easily stage a custom element or custom attribute in isolation inside a mini Aurelia application, assert how it responds to data-binding and assert its behavior throughout the component's lifecycle (bind, attached etc).
 
-## [Getting Started](aurelia-doc://section/2/version/1.0.0)
+## Getting Started
 
 If you are using JSPM:
 
-```shell
+```Shell
 jspm install aurelia-testing
@@ -30,3 +20,3 @@ ```
 
-```shell
+```Shell
 npm install aurelia-testing
@@ -37,3 +27,3 @@ ```
 
-## [Testing a Custom Element](aurelia-doc://section/3/version/1.0.0)
+## Testing a Custom Element
 
@@ -121,3 +111,3 @@ Let's start with a simple custom element that we want to test:
 
-## [Manually handling lifecycle](aurelia-doc://section/4/version/1.0.0)
+## Manually handling lifecycle
 
@@ -144,3 +134,3 @@ When testing a component sometimes you want to have tests run at certain points of the lifecycle.  To do this we can tell the component we created that we will manually handle the lifecycle methods -
 
-        component.manuallyHandleLifecycle().create()
+        component.manuallyHandleLifecycle().create(bootstrap)
           .then(() => {
@@ -184,3 +174,3 @@ nameElement = document.querySelector('.name');
 
-## [Testing a Custom Attribute](aurelia-doc://section/5/version/1.0.0)
+## Testing a Custom Attribute
 
@@ -237,3 +227,3 @@ Testing a Custom Attribute is not much different than testing a Custom Element. Let's look at how it's done by starting with a simple example custom attribute that lets you change the background color of the element it is placed on:
 
-## [Testing custom component with a real view-model](aurelia-doc://section/6/version/1.0.0)
+## Testing custom component with a real view-model
 
@@ -290,3 +280,3 @@ If you want to test a custom component with a real view-model, mocking
 
-## [Using a Real Parent View-model](aurelia-doc://section/7/version/1.0.0)
+## Using a Real Parent View-model
 
@@ -351,3 +341,3 @@ If you want to test using a custom element inside of a real parent view-model this can be done just as easily.  This can be really helpful when needing to test the state of a parent that is affected by the child custom element or attribute -
 
-## [Improving Readability with Multi-line Strings](aurelia-doc://section/8/version/1.0.0)
+## Improving Readability with Multi-line Strings
 
@@ -382,3 +372,3 @@ You can improve the readability of your complex views by using template literals in your tests -
 
-## [Helpful Properties and Functions](aurelia-doc://section/9/version/1.0.0)
+## Helpful Properties and Functions
 
@@ -397,3 +387,3 @@ The `ComponentTester` exposes a set of properties that can be handy when doing asserts or to stage a component in a specific way. Here's a list of what is available:
 
-## [Testing complex components](aurelia-doc://section/10/version/1.0.0)
+## Testing complex components
 
@@ -400,0 +390,0 @@ In some cases, the tested element is not rendered yet when the `component.create()` promise is resolved, and therefore when the actual test starts. For these situations, `aurelia-testing` and `ComponentTester` expose helper methods and functions to wait for tested elements to be present in the page.

doc/CHANGELOG.md

@@ -0,1 +1,12 @@
+<a name="1.0.0-beta.5.0.0"></a>
+# [1.0.0](https://github.com/aurelia/testing/compare/1.0.0-beta.4.0.0...1.0.0) (2018-09-25)
+
+
+### Bug Fixes
+
+* **code example:** fix to the manually handling lifecycle example ([#82](https://github.com/aurelia/testing/issues/82)) ([b0fb939](https://github.com/aurelia/testing/commit/b0fb939))
+* **waitFor:** reject with Error rather than string ([#84](https://github.com/aurelia/testing/issues/84)) ([054dab5](https://github.com/aurelia/testing/commit/054dab5))
+
+
+
 <a name="1.0.0-beta.4.0.0"></a>
@@ -2,0 +13,0 @@ # [1.0.0-beta.4.0.0](https://github.com/aurelia/testing/compare/1.0.0-beta.3.0.1...1.0.0-beta.4.0.0) (2017-11-06)

package.json

 {
   "name": "aurelia-testing",
-  "version": "1.0.0-beta.4.0.0",
+  "version": "1.0.0",
   "description": "A collection of helpers for testing Aurelia apps and components.",
@@ -5,0 +5,0 @@ "keywords": [

README.md

@@ -39,5 +39,4 @@ # aurelia-testing
 
-	```shell
-	npm test
-	```
-
+```shell
+npm test
+```

src/wait.ts

@@ -41,3 +41,3 @@ /**
         timedOut = true;
-        rj(options.present ? 'Element not found' : 'Element not removed');
+        rj(new Error(options.present ? 'Element not found' : 'Element not removed'));
       }, options.timeout)
@@ -44,0 +44,0 @@ ),

New alerts

License Policy Violation

License

This package is not allowed per your license policy. Review the package's license to ensure compliance.

Found 1 instance in 1 package

Fixed alerts

License Policy Violation

License

This package is not allowed per your license policy. Review the package's license to ensure compliance.

Found 1 instance in 1 package

Major refactor

Supply chain risk

Package has recently undergone a major refactor. It may be unstable or indicate significant internal changes. Use caution when updating to versions that include significant changes.

Found 1 instance in 1 package

No v1

Quality

Package is not semver >=1. This means it is not stable and does not support ^ ranges.

Found 1 instance in 1 package

Improved metrics

Number of low quality alerts

0

decreased by-100%

Number of medium supply chain risk alerts

0

decreased by-100%

Worsened metrics

Total package byte prevSize

320927

decreased by-0.25%

Number of package files

93

decreased by-1.06%

Number of lines in readme file

42

decreased by-2.33%

No dependency changes