Software Architect at Genzeon Corporation in Malvern, Pennsylvania, Microsoft .NET MVP, Husband, Dad and Geek.
28863 stories
·
21 followers

Angular Testing with Headless Chrome

1 Share

Configuring Angular CLI to leverage Headless Chrome for Unit and E2E tests

Headless Chrome is a useful tool for running automated tests in environments where it isn’t practical to actually launch a browser. In this article we explain how to configure Angular CLI to run your Unit and E2E Tests using Headless Chrome.

This will become important for our upcoming set of articles in The Angular DevOps Series where we will want to run our automated tests in a Continuous Integration environment.

Installation

For our convenience Angular CLI adds the karma-chrome-launcher by default as one of our devDependencies in our package.json. So, we don’t need to install anything more to use Headless Chrome.

Unit Tests

By default, when we do npm run test, our unit tests are set up to watch for updates in the code and then run each time there are changes. However, we are targeting a test script that can eventually be used for continuous integration. So, let’s configure a new npm script to run our unit tests only once using Headless Chrome and then exit.

In package.json we just need to add a new entry called test-headless in our scripts. It should look something like this:

"scripts": {
"ng": "ng",
"start": "ng serve",
"build": "ng build",
"test": "ng test",
"test-headless": "ng test --watch=false --browsers=ChromeHeadless",
"lint": "ng lint",
"e2e": "ng e2e"
},

Note the flags:

  • --watch=false
    Specifies that we only want the tests to run once and then exit instead of watching for changes.
  • --browsers=ChromeHeadless
    Specifies that we want to use Headless Chrome as the browser for the tests.

Now to run our unit tests with Headless Chrome we can use:

npm run test-headless

E2E Tests

When we create a new work space using Angular CLI, it configures Protractor to run our End-to-End tests (E2E).

We want configure our E2E tests to run using Headless Chrome. Unlike unit tests, it isn’t quite as simple as just adding a new npm script. This is because the arguments that are supported by ng e2e are different than the actual command line arguments supported natively by Protractor. But, not to worry, we can leverage the Protractor configuration file.

The Protractor configuration file for our E2E tests is:
e2e/protractor.conf.js

We need to modify the capabilities entry in our protractor.conf.js file to include a chromeOptions object like this:

capabilities: {
chromeOptions: {
args: [ "--headless" ]
},
'browserName': 'chrome'
},

In chromeOptions we have the args entry. With it, we can pass an array of string arguments into Protractor. For our purposes we only need one:

  • --headless
    Run Chrome in headless mode.

This is the minimal configuration necessary to run the E2E tests. Additionally, you may have code that relies on browser properties such as the window size. Then, you may need to add other flags such as --window-size=800x600.

To run your E2E tests use:

npm run e2e

Angular Testing with Headless Chrome was originally published in Angular In Depth on Medium, where people are continuing the conversation by highlighting and responding to this story.

Read the whole story
alvinashcraft
21 hours ago
reply
West Grove, PA
Share this story
Delete

Introducing macOS Platform Support for Syncfusion Xamarin Controls

1 Share

At the end of June, we released Essential Studio 2018 Volume 2 with a lot of new features and new controls in Xamarin. The most exciting thing about this release for our Xamarin UI controls suite is the extension of Charts, DataGrid and ListView controls’ support to the macOS platform in Xamarin.Forms. These controls are compatible with macOS 10.11 and higher versions. We will continue to add other controls gradually in consecutive releases.

Though all the existing features are supported in macOS also, they would not be complete if the interactive features didn’t work with a keyboard and mouse in macOS. Therefore, we also added keyboard navigation and mouse interaction support for these controls. The following summaries can give you an idea of what has been done in these controls apart from the existing features.

Lots has been done in datagrid to make it work seamlessly with the keyboard and mouse in macOS. The most interesting interaction is that you can swipe a grid row with two fingers using trackpad to show contextual actions such as delete button, edit button, etc. You can enter edit mode by double-clicking on a cell and exit the edit mode by pressing the Esc key. You can navigate through the grid rows using Up arrow, Down arrow, Page up, Page down, Home, and End keys. It is possible to do multiple selection using the Up and Down arrow keys along with the Ctrl and Shift key modifiers.

In charts, you can use the mouse to activate tooltip and trackball features and interact with data points and legend items. You can also zoom the chart by scrolling the mouse wheel or zoom and pan the chart using the trackpad.

With list view control, you can select items using the mouse and navigate through them using the Up and Down arrow keys.

It’s not over yet! There are more improvements planned for macOS, especially in data grid, in the upcoming release.

What’s next

You can check out these controls in action in this expense tracker demo application. This is a simple, real-world application developed in Xamarin.Forms and MVVM that showcases how these controls work in the iOS, Android, UWP, and macOS platforms.

Displays the overview of expense details using datagrid

Displays the overview of expense details using datagrid

Displays transaction history in listview

Displays transaction history in listview

Visualize expense trends and summary using bar and pie charts

Visualize expense trends and summary using bar and pie charts

If you need any other control as an immediate requirement, please let us know in the comments below. This will help us prioritize the next set of controls to implement. You can also contact us through our support forum or Direct-Trac. We are happy to assist you!


Read the whole story
alvinashcraft
21 hours ago
reply
West Grove, PA
Share this story
Delete

Creating Vue.js Client Side – Preparing Project and Project Structure Overview

1 Share

Now, that we have finished the backend (.NET Core Web API part), we have to create the frontend part. In this series, we are going to use Vue.js. It is a pretty new framework but it is already attracting a lot of attention. In a comparison to other popular frameworks, Vue.js is much easier and straightforward to use, so if you are a beginner it should be easier to start with.

We are going to build our frontend as an SPA (Single Page Application). That is the type of web application that never reloads because it’s rewriting the content of a single HTML file resulting in smoother user experience and feeling like its native desktop app.

For the complete navigation of this series, you can visit Vue.js Series.

To download the source code for this part, visit Preparing Vue.js Project Source Code.

Let’s start.

This post is divided into several sections:

Installation of Vue CLI and Starting a New Project

First, we are going to install the Vue CLI (Command Line Interface) which will help us initialize a new Vue application. To install the Vue CLI we are going to type this command at the terminal:

npm install -g vue-cli

After the installation, we are going to create a new project by using the official Vue.js Webpack template. Webpack is a module bundler which will generate static assets from our modules and dependencies.

To create our first Vue.js project, let’s navigate to the folder where we want to create a project and type in terminal:

vue init webpack AccountOwnerClient

After some time, the wizard is going to ask us a couple of questions.

Project Details

The first question is Project name and we are going to type account-owner-client because node package name must not contain capital letters and best practice is to type a name in Kebab Case.

The second question is Project description and we are going to type Account Owner Client for this one.

The third question is Author and we are going to type our name and email in the format Name Surname <email@domain.tld>.

Configuring Vue.js and Linter

The fourth question is whether we want the Runtime + Compiler or just the Runtime. We want the Runtime + Compiler because we are going to write Vue.js components and for that we need Compiler.

The fifth question is whether we want vue-router and we will type Y because we are going to have several pages to navigate through.

The sixth question is whether we want ESLint. ESLint is a great package which takes care of our code style and forces us to write the code by strict rules like the code indentation, writing space before brackets on function definitions, writing a semicolon and a lot of other things. We would advise you to use ESLint, so we are going to answer with Y.

The seventh question is which ESLint preset we want to use. ESLint preset is set of rules and there are a lot of presets because people have different preferences and, for example, some people like writing semicolon at the end of the line while others don’t. Wizard is asking us if we want Standard preset, Airbnb preset or to write our own rules. You can learn more about the Standard rules here, and about the Airbnb rules here. Personally, we like writing a semicolon and the Airbnb rules force that while the Standard does not. But, we don’t like writing a comma on the last element of JSON and that’s what the Standard rules are forcing us. On the other side, the Airbnb does not, so, we are going to use our own ESLint rules. Of course, you can choose whatever suits your style and change that later in the .eslintrc.js file.

Configuring Tests and misc.

The eighth question is about unit tests and we are going to type n because we will not cover any type of tests in this series.

The ninth question is about e2e tests and we are going to type n as well.

The tenth and the last question is whether wizard should run npm install for us to install all dependencies we need. We are going to choose Yes, use NPM.

 

If you’ve followed everything carefully, you are going to see this as a result:Vue Init Project - Creating Vue.js project

Let’s wait for the npm to install everything for us and then open the project with any code editor and analyze the project structure. Our advice is to use Visual Studio Code because it has great extensions which can help us a lot with building Vue.js applications. Also, our advice is installing the Vue.js Extension Pack as well.

Project Structure Overview

After we open the project with a code editor, we are going to notice the following folder structure:
Project Structure - Creating Vue.js project

Explanation of the most important files and folders:

  • src – Our project source code:
    • assets – Module assets which will be processed with Webpack
    • components – This is where we keep our UI components
    • router – Here we write routes and connect them to our UI components
    • App.vue – This is entry point component, it’s the main UI component in which all the other components will render
    • main.js – Entry point file which will mount App.vue – our main UI component
  • assets – pure assets which will not be processed with Webpack
  • index.html – You may remember that SPA application always rewrites the content of one file, so, this is that file. This is the file which we are serving to our visitors. After building a project, this file will load static files which were bundled with Webpack

Let’s take a look at the index.html file:

<!DOCTYPE html>
<html>
 <head>
   <meta charset="utf-8">
   <meta name="viewport" content="width=device-width,initial-scale=1.0">
   <title>account-owner-client</title>
 </head>
 <body>
   <div id="app"></div>
   <!-- built files will be auto injected -->
 </body>
</html>

The only important thing in this file is a div tag with id app, which is going to be replaced with our App.vue component. On the next line, we can notice the comment that says:  “built files will be auto injected”. So, our js file, which is bundled with Webpack, is going to be injected below the div with id app.

You may remember that main.js is our entry point, right? Let’s take a look at main.js file which is the first file  to be executed when the application starts:

import Vue from 'vue';
import App from './App';
import router from './router';

Vue.config.productionTip = false;

new Vue({
  el: '#app',
  router,
  components: { App },
  template: '<App/>'
});

In this code example, we can notice that our main.js imports the Vue module. On the next lines, we can see two additional imports. One is our App component (App.vue) and another one is the router, and for all the import statements we don’t need to specify an extension.

Furthermore, we instantiate a new Vue component which is going to mount our App.vue component inside a div with the id app attribute – you remember div with id app in index.html? Finally, we notify our Vue component to use the router.

Component Structure

Let’s take a look at the App.vue file:

<template>
 <div id="app">
   <img src="./assets/logo.png">
   <router-view/>
 </div>
</template>

<script>
export default {
 name: 'App'
};
</script>

<style>
#app {
 font-family: 'Avenir', Helvetica, Arial, sans-serif;
 -webkit-font-smoothing: antialiased;
 -moz-osx-font-smoothing: grayscale;
 text-align: center;
 color: #2c3e50;
 margin-top: 60px;
}
</style>

Every Vue component may contain a template, a script, and a style section.

  • The template is a visible content of the component
  • The script is a logic of the component
  • Style, you guessed it, is a style for a template

Template

In a template, we can use native HTML tags as well as our custom Vue components. Here we can see the <router-view/> element and that’s the place where our router is going to render a matching component for that route. We are going to analyze the router file in a few moments.

Script

In the script tag, we write logic for that component. In this component, we only have the name property because this component isn’t dynamic, it is nothing other than the wrapper around our router-view. We are going to cover writing components in the next part of this series.

Style

Here we can write a style for a template. Style can be scoped or global. The scoped style is written this way: <style scoped>. That type of style only affects the template of that component and root element of child components so there is no way for style to leak to another component. Counterwise, non-scoped style will be shared between components.

Router

Let’s take a look at the router/index.js file:

import Vue from 'vue';
import Router from 'vue-router';
import HelloWorld from '@/components/HelloWorld';

Vue.use(Router);

export default new Router({
 routes: [
   {
     path: '/',
     name: 'HelloWorld',
     component: HelloWorld
   }
 ]
});

In this file, we import Vue again so we can notify Vue to use Router which is imported from a package named vue-router. Furthermore, we import the HelloWorld component from the components folder. The @ symbol in a path is a Webpack alias for the root of the project, so whenever we want to import something and to navigate to the root folder we can use @.

Next, we notice instantiating the Router and list of routes. We may notice the path / which means when we open our application and navigate to the root (/) it is going to serve us the HelloWorld component. The content of that component is going to be served in the App.vue component inside the <router-view/> tag, remember?

We are not going to analyze the HelloWorld.vue file because it’s pretty much the same as the App.vue file. It’s just another component with some content in a template and we are going to see how it looks like, but this time in a browser.

Starting Our Application

Now that we understand the code, it’s time to run the application and see everything on a live example.

Let’s type this command in terminal:

npm run dev

This is going to run our application in a development mode. Afer running that command, let’s open our web-browser and navigate to http://localhost:8080/. If everything is OK, we should be able to see the starting page of our application:
Starting Our Application - Creating Vue.js project

We may notice the Vue.js logo which is the part of the App.vue component. Under the logo, we see the content of the HelloWorld.vue file which is rendered inside the <router-view/>element of the App.vue component. The application is rendering the HelloWorld.vuecomponent because we are on the / route.

Conclusion

Excellent.

You have learned how to create and run a new Vue.js project. But this is just a beginning of this great journey! We still have a lot of work to do and to try out the great Vue.js features!

By reading this post you’ve learned:

  • The way of creating a new Vue.js application
  • What is SPA and why it’s a great way of writing applications
  • The overview od Vue.js components
  • The basics of Vue.js routing

In the next part of the series, we are going to show how to install a third-party library, create navigation and also how to use routing.

If you have enjoyed reading this article and if you would like to receive the notifications about the freshly published .NET Core content we encourage you to subscribe to our blog.

The post Creating Vue.js Client Side – Preparing Project and Project Structure Overview appeared first on Code Maze.

Read the whole story
alvinashcraft
21 hours ago
reply
West Grove, PA
Share this story
Delete

Reporting on Unit Tests with VSTS Containerized Apps

1 Share

I am a purist at heart and when I do something I want to take full advantage of the tools I am using. In the case of Docker, that means emphasizing that ALL of my code should run in the same container as my final product. What is the value otherwise?

To that end, I set up about exploring how I might report on unit tests with a VSTS build. It is not an easy process because, in my view, VSTS and .NET do not naturally lend themselves to the containerized architectures. Microsoft is working hard on changing this and have made great strides but, there are still some issues to work out.

However, in this case the central problem has to do with what Docker creates, an image, which is immutable meaning, during its construction you can not read from it, nor would you want to.

Approach 1: Run the Tests before Image Creation

The simplest approach is to run the unit tests before you create the image and add a dependent build phase which only executes if all unit tests pass. While this is simple and would work, it violates, in my mind, the principles of containerization.

Code is run in the same way for all environments

This matters for testing as it is the idea spot you might find a difference. If someone was using a different version of a library and it worked there and even worked on the build server but didnt work in the container, you would never know until you deployed.

Admittingly this is rare for any experienced development team who would be keeping close tabs on this but, it does happen (happened at West Monroe when a member of our team insisted on using the Alpha branch while everyone else used Stable for Xamarin.

My goal was to find a way to perform the unit tests in the very same containerized environment the code would run. So, I turned to the God of Wisdom: Google

Approach 2: Docker Compose to the rescue

Docker Compose is one of those tools that was created for one purpose but, I think, ended up fulfilling another. While you can still deploy production code using Compose, the trend right now is towards Orchestration with something like Kubernetes. Still, Compose is great for applications that wont use Kubernetes but still need mimic local representations of production dependencies.

In my searching I came across this fantastic article on Medium by a fellow developer who found an ingenious way to accomplish what I was seeking using Docker Compose.

Running your unit tests with VSTS and Compose

The gist is, we can use a Dockerfile which creates a “test” image which has no ENTRYPOINT defined. We can then create a docker-compose file which references that Dockerfile and specifies the ENTRYPOINT in the compose file as the dotnet test command. Here is a sample from my final output.

version: ‘3’
services:
  myapp.tests:
    build:
      context: .
      dockerfile: MyApp.Tests/Dockerfile
    entrypoint: dotnet test MyApp.Tests/MyApp.Tests.csproj –logger trx -r /results
volumes:
  – /opt/vsts/work/_temp:/results

As you scan this Compose file it becomes a bit clearer what is happening. VSTS supports the ability to perform a Docker Compose command. We use this to launch our Test Image and mount its results location for the test results to a local folder (last line above). This way when we run our subsequent step to report the results we have access to the files (they are built and stored in the container remember).

Note: I recommend keeping the directory the same since you can be sure it exists

Here is the Docker Compose up command we will use from the VSTS task

up –abort-on-container-exit –build

Note: the task will preprend docker-compose for us, so we need only specify the arguments.

The –abort-on-container-exit and –build flags just ensure that we build the container image if it is not cached already and the container is exited when our ENTRYPOINT command finishes.

Finally, we come to publishing our Test Results, we can use the existing VSTS Publish Test Results task. Point the task at our mounted directory, specify the desired extension as .trx and the test type ise VSTest (even if you are using a different runner, say NUnit).

Now you should be able to run and see your test results. Should point out that, since we are using dotnet test as our entrypoint, the task WILL FAIL if a test does not pass. So keep that in mind so you can create the proper control flow to not create Docker images from builds that do not have passing unit tests

I hope that helps, I hope you got some good information out of this. Be sure to visit the link above and send thanks to Christian. That article really helped me out.

View story at Medium.com



Read the whole story
alvinashcraft
21 hours ago
reply
West Grove, PA
Share this story
Delete

Jon Skeet on Making StackOverflow More Inclusive

1 Share

Episode 524

Jon Skeet on Making StackOverflow More Inclusive

Read the whole story
alvinashcraft
21 hours ago
reply
West Grove, PA
Share this story
Delete

Podcast 094 - Jeremy Miller on Lamar

1 Share

Jeremy Miller has created an open-source IoC tool called Lamar. This episode is sponsored by Smartsheet.

Show Notes:

  • StructureMap has been sunsetted

  • Instead, consider Lamar for your IoC container needs.

  • Nested containers

  • At one point I was rambling about ASP.NET Core’s inability to use the service locator pattern. Some quick points:

    • Don’t use Service Locator, there are lots of other better patterns to use.

    • DO NOT DO IT.

    • If you absolutely need it: here’s a blog post about it.

    • I was incorrect in the podcast by making a sweeping statement about ASP.NET Core not having service locator. But for a very specific, narrow case where I wanted to use the service locator pattern recently, I was unable to do so. This might have been my own failing, or something that just isn’t possible with the built-in ASP.NET IoC. I have not tried this very specific, narrow use case with Lamar yet.

  • I plugged my book, AOP in .NET yet again.

  • Lamar is named after Mirabeau Lamar (a hero of the Texas revolution)

  • Paper: Inversion of Control Containers and the Dependency Injection pattern by Martin Fowler

  • Gitter room for Lamar

Want to be on the next episode? You can! All you need is the willingness to talk about something technical.

Music is by Joe Ferg, check out more music on JoeFerg.com!

Read the whole story
alvinashcraft
21 hours ago
reply
West Grove, PA
Share this story
Delete
Next Page of Stories