I'm developing single page application on AngularJS for learning. My project is located on Apache HTTP Server on another computer, I use WinSCP synchronisation while developing so that it is always the last version of my work.
Halfway through (actually, when I has already finished the biggest part the application), I realized that I don't have any tests and I should learn how to test what I do not just manually. I decided to try writing E2E tests for my AngularJS application using Karma Test Runner.
I installed Karma via npm, initialized it (karma init test/karma.conf.js), but what happens now?
I tried karma start test/karma.conf.js it launches Chrome (as I stated in config) and says that
Karma - connected
Chrome 26.0 (Windows) is idle
even though in conf file there are specified my test file:
files = [
'test/first_test.js'
];
And that's what inside it:
describe('my app', function() {
browser().navigateTo('/');
it('should then be.', function() {
expect(browser().location().url()).toBe('/login');
});
});
Thanks in advance!
EDIT: I realized, it's not just 'Chrome is idle', there's also console log error:
Uncaught ReferenceError: browser is not defined
Any ideas? I'm so confused right now.
Browser is only defined inside of beforeEach. Try this:
describe('my app', function() {
beforeEach(function(){
browser().navigateTo('/');
});
it('should then be.', function() {
expect(browser().location().url()).toBe('/login');
});
});
Alright, looks like I solved it myself.
I should have added
ANGULAR_SCENARIO,
ANGULAR_SCENARIO_ADAPTER,
to the files property of karma config file. After that, I progressed a little bit, but still got a lot of troubles, but essentially the main was that I got error that resumeBootstrap was undefined. My app was using AngularJS 1.0.4, but it looks like Karma's Adapters are for 1.0.6+ only. Upgrading app to 1.0.6 helped with resumeBootstrap.
Regarding testing the app on external server:
proxies = {
'/': 'http://another.internal/app/'
};
and don't forget to change links to CSS and JS files in app's index.html from local (css/style.css) to web (//another.internal/app/css/style.css).
Related
I'm building a Vue.js application using Vuexy BootstrapVue template, deployed in a Docker container.
I am finding that when we deploy updates to our web app, that the User has to do a hard-refresh in their browser to load the latest version of the app, otherwise they'll be navigating around a cached version.
Is there a way for me to force a client browser to load the latest version for a User?
Either on every load, or every few hours?
(I've tagged Bootstrap-Vue for transparency, but don't actually know if it has any bearing on this issue)
You are facing the cache problem and there is multiple ways to handle this.
Cache Control
You can control the cache with the header with max-age or no-store, no-cache to simple disable it, like this question/answer: How do we control web page caching, across all browsers?
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control
https://csswizardry.com/2019/03/cache-control-for-civilians/
Cache busting
Aappending a version (example: 1.0.0) to query string of the script tag:
<script src="path/to/your/app.min.js?v=1.0.0"
and change that version for every build.
Hashing the script file
You can also use some webpack/rollup config to build the script with a hash, like app.bf43112.js
webpack
const config = {
output: {
path: PATHS.build,
filename: "[name].[contenthash].js",
},
};
Rollup
const isProduction = process.env.NODE_ENV === 'production';
export default {
output: {
sourcemap: true,
format: 'iife',
name: 'app',
file: isProduction ? 'bundle[hash].js' : 'public/build/bundle.js',
}
};
Reference: Hashed file names using Rollup
Service Worker
Another solution, that I never tested, but sounds a good method.. is creating a service worker to control how retrieve the js file:
https://developers.google.com/web/ilt/pwa/caching-files-with-service-worker
You can do things like deleting the cache, responding the cache with a response that you manually fetch with js, etc.
I've just moved an app over to the vue cli, but i'm having an issue with getting the PWA to work. When its trying to load it up theres an console error
Uncaught (in promise) bad-precaching-response: bad-precaching-response :: [{"url":"/wwwroot/index.html?WB_REVISION=xxxxxxx","status":404}]
Thing is i'm not really sure where this error is commminng from. The actual sire loads fine, and all the asserts are ok, but thw PWA index.html seems to be loading from the wrong place. its in /index.html not /wwwrooot/html. I'm not sure why its trying to load from here. This is what the vue.config looks like
pwa: {
name: 'app Portal',
themeColor: '#CC0001',
msTileColor: '#CC0001',
appleMobileWebAppCapable: 'yes',
appleMobileWebAppStatusBarStyle: 'black',
workboxOptions: {
exclude: /\.cshtml$/,
/*
docs: https://developers.google.com/web/fundamentals/primers/service-workers/lifecycle#skip_the_waiting_phase
a new service worker does not serve pages until the old one releases control
this is called the waiting phase
skipWaiting means the new one immediately takes control. this may cause issues with people still using your application
*/
skipWaiting: true,
},
},
``
Any ideas why the PWA seems to be loading the index.html from the wrong place?
I use the pwa webpack config navigatefallback to fix this issue please see: https://developers.google.com/web/tools/workbox/modules/workbox-webpack-plugin#generateSW-navigateFallback
Also pwa can fail with history mode enabled on the vue Router:
here are some questions that i think will get you in the right direction:
PWA doesn't load when router is in history mode (Vue CLI 3 based project)
and
Vue Router History Mode with PWA in Offline Mode
When creating a standard vue app (using vue-cli v3.0) and including #feathersjs/feathers in order to implement a connection with a feathers API, I get an error with Internet Explorer 11 (SCRIPT1010: Expected identifier)
The bottom line is to find an easy way to solve issues like this, because on bigger projects one could easily find lots of library issues and sometimes is necessary to support at least one version of Internet Explorer (at least from the business point of view)
I read on feathers site (https://docs.feathersjs.com/api/client.html#module-loaders) that the library uses ES6 so in this case it must be transpiled in order to work in a browser like IE11.
So I tried this but had no luck at all:
// vue.config.js
module.exports = {
baseUrl: '/',
transpileDependencies: [
'#feathers/commons',
'#feathers/errors',
'#feathers/feathers',
'debug'
]
}
and got errors even in chrome: Uncaught ReferenceError: exports is not defined
I created a project to show this error: https://github.com/riescorp/vue-internet-explorer
One should be able to use IE11 for this app, even if it doesn't work fast or looks nice, but works.
I believe the process should be the same as following the directions on the Vuetify website in the section of this page titled "IE11 & Safari 9 support" (scroll to the bottom): https://vuetifyjs.com/en/getting-started/quick-start
I've not had to do anything else in my projects, that I can remember.
I finally manage to solve this issue.
This is the babel.config.js config that does the trick:
module.exports = {
presets: ['#vue/app'],
plugins: ['#babel/transform-modules-commonjs']
}
Also there was a typo in my vue.config.js it should look like this:
// vue.config.js
module.exports = {
baseUrl: '/',
transpileDependencies: [
'#feathersjs',
'debug'
]
}
Finally, when using feathers this line wouldn't work:
.configure(restClient.fetch(window.fetch))
so you can use import 'whatwg-fetch' to solve it (remember to install it npm i whatwg-fetch)
New to TestCafe.
Expected
Given .js below, expected behavior when running testcafe chrome this.js is to click on the header logo.
Actual
Uncaught ReferenceError: pagespeed is not defined (at the click below).
On our prod site, this error doesn't happen so most likely some configuration (possibly my version of Apache?) but I wanted to make sure there weren't any TestCafe specific issues. Followed installation using the standard docs (npm)
Thanks in advance!
import { Selector } from 'testcafe';
fixture `A set of examples that illustrate how to use Little Passports`
.page `https://xxx.xxdev.us/`;
test('My Company', async t => {
await t.
click('.header-logo');
});
I think I'll currently get around this by adding -e, but I'll keep this open just in case there's something else to consider...
By default, a test fails when there is a JavaScript error on page. The "-e (--skip-js-errors)" parameter allows running tests by skipping this JS error.
To check if there are any errors on your page, open your browser console. If there are any, you can either fix the errors at the application level (a preferable approach) or skip them during test run using the "-e" parameter.
We're writing an app using webpack and babel-core 5.8.25.
At one point in time, this happens:
someArray.map(item => {
const updatedItem = Object.assign({}, item); // silently fails here... doesn't even continue the code
updatedItem.prop = 'something cool';
});
This is obviously compiled before hitting the browser. It works in the latest version of Chrome and the latest version of iOS Safari, but in Safari 8.0.7, it fails silently (no error thrown... just doesn't go past that line).
This, however, works as expected (using lodash):
someArray.map(item => {
const updatedItem = _.extend({}, item); // the important part
updatedItem.prop = 'something cool';
});
Any idea? I tried poking around the internet regarding this, but to no avail.
Object.assign works in Chrome because Chrome supports it natively. babel-loader on its own only converts ES6 syntax to ES5 syntax, it does not do anything to make ES6 library functionality available. The easiest way to do that with Webpack is to change your config from something like
entry: 'app.js'
to
entry: ['babel-core/polyfill', 'app.js']
// Or with Babel 6:
entry: ['babel-polyfill', 'app.js']
so that Webpack will also bundle and run the polyfill before executing your application. Babel provides /polyfill as an easy way to load the polfill, but it is optional because not everyone wants to use it, and because there are many polyfills available and the one Babel uses, core-js is just one of many.