What is Ember.js?

Editor
Aeturnum
8 min readJul 9, 2019

--

Ember.js is a MVC (Model-View-Controller) JavaScript framework used to develop large client-side web applications. In comparison to other JavaScript MVC frameworks, it gives you the ability to write organized and structured code. According to the Ember.js website, this enables you to build “ambitious” web applications.

In Ember.js, route is used as a model, handlebar template as views and controllers manipulate the data in the model.

If you want to build a single-page web application that pushes the envelope of what’s possible on the web, Ember.js is the right choice for you.

Figure 1.0 The structure of the early web (left) versus the promise of Ajax (middle) versus modern web application

Early websites were relying on the full-page refresh approach shown at the left in figure 1.0. With the arrival of the asynchronous call came the ability to send specific parts of the website for each response, as shown in figure 1.0 (middle).

In Ember.js, the user receives the full website once, upon the initial request. So it increased initial load time but significantly improved performance for each subsequent user action, as shown in figure 1.0 (right).

Let’s take a closer look at each of the MVC components.

· Controller layer — Built with a combination of routes and controllers

· View layer — Built with a combination of templates and views

· Model layer — Built with a combination of model and ember data.

Figure 2.0 The parts that make up Ember.js and how they fit in with the MVC pattern

Models and Ember Data

This layer is responsible for any server-side communication as well as model-specific tasks such as data formatting.

Ember model uses ember data to dramatically simplify your code while improving the robustness and performance of the application.

Controllers and the Ember Router

The layer between the model and view is the controller layer. There are a couple of controllers, most notably the “Ember.ObjectController” and “Ember.ArrayController”.

The Ember Router is the mechanism that updates your application URLs and listens to URL changes. Each route can have a number of sub-routes, and you can use the router to navigate between the states in your application.

Views and Handlebars.JS

The view layer is responsible for drawing the elements on the screen. Ember.js has a sophisticated system for creating, managing and rendering a hierarchy of views that connect to the browser’s DOM. Views are responsible for responding to user events, like clicks, drags, and scrolls, as well as updating the contents of the DOM when the data underlying the view changes.

Ember.js uses Handlebars.js as its template engine. Handlebars.js provides the power necessary to let you build semantic templates effectively with no frustration.

Ember.js is most likely Convention over Configuration. This means that instead of writing a lot of boilerplate code, Ember can automatically deduce much of the configuration itself, such as automatically deciding the name of the route and the controller when defining a router resource. Ember even increases the bar by automatically creating the controller for your resource if you never define it specifically.

Ember includes both an excellent router and an optional data layer, called ember data. Unlike AngularJS and BackboneJS frameworks, which have a very minimal data layer (Backbone’s Collection/Model and Angular’s $resource), Ember comes out of the box with a full data module which integrates really nicely with a Ruby-on-Rails back-end or any other RESTful JSON API that follows a simple set of conventions. It also provides support for setting up fixtures for developing against mock API and testing.

When it comes to the design of Ember.js, performance has been a major goal. Concepts such as The Run Loop, which ensures that updated data only causes a single DOM update even if the same piece of data was updated several times, along with caching of computed properties, and the ability to precompile the HandleBars templates during the build time or on your server, help to load and keep your application running fast.

AngularJS and EmberJS

AngularJS and EmberJS are similar frameworks on a number of levels, but also different in several elements. AngularJS, for example, will display a large static data set more quickly than EmberJS, but EmberJS will make it easier to add interactivity to that large data set and will handle changes more efficiently. Furthermore, while both are opinionated frameworks, EmberJS takes a somewhat stronger position than AngularJS, which can make some tasks around porting an existing application challenging to complete. In the end, either architecture has its own trade-offs, and determining which framework is right for you is simply a matter of evaluating your application’s needs versus the strengths of each framework.

Best practices for real world Ember deployment

“Ember CLI” is a command line tool for quickly generating web apps structure. The CLI is a very useful tool and will probably be the standard way to create ember apps in the future. Using Ember CLI slightly changes the way the app is written.

How to use Ember-CLI?

First, you have to download and install “node.js” to your computer.

Once you have node installed, you can get ember-CLI by opening up a command prompt and running:

$ npm install -g ember-cli

To create a structure for the application you can run:

$ ember new project-name

This will create a folder called releases with everything needed to start coding. Change the current directory into releases and run:

$ ember server

Now you should be able to visit “http://localhost:4200” and see a very basic page.

Is The Three Test Values Sufficient Enough To Perform A Black Box Test At All Times?

The Boundary Value Analysis is a popular test technique. It is easy to understand and easy to explain to the testers and the non-testers alike. Part of the ease in comprehension is based on the elegant and simple examples that can be used to explain the technique. A boundary value is introduced, and it’s explained that the three values are needed to test the boundaries thoroughly. But this article tries to show that three values are not enough to perform a black box test to prove that a boundary has been implemented correctly.

First of all let’s find out what is meant by Equivalence Partitioning (EP). The basic idea of EP is quite simple. If you expect the same result from two tests, it’s sufficient to run one of them. But this idea is based on two assumptions.

1. Every test input can be divided into several classes.

2. System processes every possible input value in a class exactly the same way as it process every other input value in the class.

(Note that test outputs also can be considered the same as above)

For an example: A bank system accepts clients aged 55 years old or younger. All other potential clients are not accepted. Ages are entered into the system under test in whole years.

Considering above example, we can divide two possible classes as follows:

1. Clients aged 55 and younger will be accepted (we call this class as valid class)

2. Clients aged 56 and older will be rejected (we call this class as invalid class)

When using EP for above example we can test the system with following test values.

1. 15 to represent valid class

2. 75 to represent invalid class

Note that the above values are chosen arbitrarily due to the assumptions we make on EP technique. Also the values 20 and 80, or 40 and 65 could have been chosen.

Let’s find out what is Boundary Value Analysis (BVA). While testing, it was discovered that some defects seemed to cluster around values outline the equivalence classes (boundaries). The boundaries are being incorporated into programming code during programming. In the example above, focusing on the “younger than or equal to 55 years old” boundary, code can say as “IF age <= 55”.

Since this boundary is code, this is where programming error most likely could occur. In Boundary Value Analysis (BVA) test technique this means to test with test values on, just below, and just above the boundary to detect any possible programming fault made in rational operator (<, <=, =, >, >=, <>). The defect could exist regarding the rational operator programming faults in the <= sign. This operator could wrongly be programmed as >, >=, = , <, <> or = instead of <=. Let’s check whether operator fault can be found using three values considering BVA.

In Summary, the use of BVA comes down as follow:

1. Identify equivalence classes.

2. Determine Boundary Values.

3. Specify test cases using three values for each boundary.

But BVA is often used in black box testing and test professional has no insight into the implementation of the functional design above example also can be coded as “IF age < 56”. If so, let’s find out same three values enough to detect the fault.

As shown in the table above, if “<> 56” was (wrongly) programmed instead of the intended “< 56”, the actual results and the expected results are identical for all three BVA test cases. Therefore, the fault will not be detected for the black box testing.

As a remedy, we can follow the following steps to find out another suitable test value to detect the fault.

Identify the equivalence classes.

According to the example,
IF Age <= 55 is valid class. (Age < 56)
IF Age > 55 is invalid class.
Get closest value for the boundary value from each valid and invalid class.
From Valid EP (55)
From Invalid EP (56)
Get the next nearest value for selected values in step#2.
From Valid EP (54)
From Invalid EP(57)
Specify test cases, using four test values per boundary.

Let’s apply identified test values for the example.

By adding the extra test value (57) the fault (“<>” being programmed instead of “<”) will, even when using Boundary Value analysis as a black box technique, be found.

Summary & Conclusion:

When we perform BB testing using EP and BVA techniques, we are use only the three test values and I have proved that we could have miss some failures. To avoid and increase the probability of error detection, we could have used the four test values, which are taken from each valid EP and invalid EP closest to the boundary value.

Rule of Thumb:

Four test values are chosen:

· Two values from the valid EP, which are closest to the boundary value,

· Two values from the invalid EP, which are closest to the
boundary value,

--

--