A Beginner’s Guide To Foundation Testing

How to develop a web application in Foundation?

While this blog focuses on the Foundation testing of websites, as a tester, it is important to know the elements involved in the development. Unless we are familiar with associated elements, we may not be able to explore unique scenarios about the Foundation framework.

• To start the development, first, install the Foundation framework.
• Click the Download Foundation 6 button to download the CSS as a compressed file.

• Extract the compressed CSS file to reveal the contents.

The compressed file has three components:

• CSS – The CSS folder contains the CSS part of the Foundation framework, including the app.css file, which the developer can alter according to the requirement. Including it, this folder contains three files:
• app.css
• foundation.css
• foundation.min.css
• JS – The JavaScript part of the framework is provided in the js folder. This folder has the following files:
• app.js
• foundation.js
• foundation.min.js
• what-input.js
• jquery.js
• index.html – This is the ready-made web page provided by Foundation. Since they focus a lot on the grids and their ability to offer a flexible grid system, this page will show off their strengths that can be altered and played around by beginners.

As a developer and tester, it’s recommended to download the compressed file and understand all the grids used in index.html. It will come in handy when test cases are required for testing.

Now, we have the Foundation framework installed on our local system. Let’s put down some light code to understand the Foundation framework a bit deeper.

How to code a Foundation web page?

Let’s create our new file index.html (a standard name for the home or landing page). Then, edit the code as follows:

<!doctype html>
<html class="no-js" lang="en" dir="ltr">
  <head>
    <meta charset="utf-8">
    <meta http-equiv="x-ua-compatible" content="ie=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <link rel="stylesheet" href="css/foundation.css">
    <link rel="stylesheet" href="css/app.css">
  </head>
<body>

In this code, we link the stylesheets to the web page through the < link > tag.

Now, we create a container using the grid-container class which resembles the “container” class used in Bootstrap for the same purpose.

<div class="grid-container">

This container will require some nested code that will eventually be seen on the web page. Let’s put down a grid system here to use the Foundation’s strength:

<div class="grid-x grid-padding-x">

This looks a lot different from normal CSS grids used in Bootstrap. The problem with conventional grids is understanding the axis of the grid and the normal flow of element addition. If the grid is “row,” then the meaning of columns and row is different than when the grid is “column.” This is somewhat confusing for code readers and developers.

The Foundation framework has addressed this problem by providing classes that mention the axis of the grid. In the above code, “grid-x” is used, which means the grid is along the x-axis. Another class, “grid-padding-x” is used to provide padding between the gutters along the x-axis. Both these classes solve the conventional grid problem.

When we use the grid-x and grid-y system instead of normal “row” and “column,” we need to mention the column as “cells.” So no matter what axis is defined, the cells are adjusted and contain a consistent meaning which helps in development.

<div class="large-8 medium-8 cell">
    <div class="grid-x grid-padding-x">
      <div class="large-12 cell">
        <div class="primary callout">
          <p><strong>This grid expands to 12 sections.</strong></p>
        </div>
      </div>
    </div>
    <div class="grid-x grid-padding-x">
      <div class="large-6 medium-6 cell">
        <div class="primary callout">
          <p>This is a half length grid i.e six cell</p>
        </div>
      </div>
      <div class="large-6 medium-6 cell">
        <div class="primary callout">
          <p>This is a half length grid i.e six cell</p>
        </div>
      </div>
    </div>
  </div>

The above code brings the output as follows:

In the remaining space of the grid, we can add all the types of buttons offered by Foundation:

<div class="large-4 medium-4 cell">
    <h5>Let's explore buttons:</h5>
    <p><a href="#" class="button">Simple Button</a><br/>
      <a href="#" class="success button">Success Button</a><br/>
      <a href="#" class="alert button">Alert Button</a><br/>
      <a href="#" class="secondary button">Secondary Button</a></p>
  </div>

Add the JavaScript libraries at the end so that JS and DOM load in perfect sync according to the web elements:

<script src="js/vendor/jquery.js"></script>
<script src="js/vendor/what-input.js"></script>
<script src="js/vendor/foundation.js"></script>
<script src="js/app.js"></script>

Combine all the code and we get the following output:

With this, we have crafted an extremely simple web page and added grids on it. The classes we used show us how the Foundation framework helps encourage development phenomena that easily cover the anomalies of other popular front-end frameworks.

How to develop an email in Foundation?

At the start of this blog on Foundation testing, we mentioned the primary difference between Foundation and any other front-end framework is its ability to make email designing faster, easier, and much more efficient. The major problem with an email is that it is hard to make it responsive. As a result, sometimes you may receive an email that will look like this:

Emails are hard to design, and if you are using conventional HTML to do so, you might be using a lot of < table > and < tr > tags to design it. This makes a complex nested component hard to write, debug and read. The Foundation framework tries to address these problems through its offerings. Before designing the email, we need to set things up on our system as we did in the previous section while developing a web app.

For this, download the CSS Version Starter Kit from the official Foundation for Emails website.

The compressed file will contain two components:

• foundation-emails.css
• index.html

They will play the same role as they did in web app development. The developers can use the same basics here and build the email. At this point, developers can freely develop the email design using conventional methods of < table > and “row” classes and other grid structures. However, if you wish to skip that, we need to learn about Inky.

Inky Template – Foundation Framework Originals

Readers open emails on phones, tablets and desktop clients, so an email built with Foundation has to render correctly on any device the user is using. Inky tries to solve this problem by providing clean syntax.

Inky does not let you get trapped in the complex net of < table > tags which sometimes expand to even twenty nested blocks. Instead, you can just use the syntax as:

<row>
    <columns>This is a column.</columns>
 </row>

This will be converted to six table tags behind the scenes, but as a developer, you just need to keep it simple at your end and let Inky do the rest of the job. As a result, the final code will be much shorter, and the developers can focus more on design.

However, by learning web development and email design, our work is not done yet. Web pages developed need to be tested for their quality and may undergo further improvements if required. The next section of this Foundation testing guide focuses on the same practice.

Introduction to Foundation Testing

The last section of this tutorial revolves around the testing part of a Foundation-built web application. A method or a process through which we ensure that the application will not break further into the future, which means if there are any glitches, they need to be rectified before release.

Foundation Testing of Emails

Firstly, the easier part is testing the emails written using Foundation. Emails are simple in design and may not require complex testing as done in the web application department. This eliminates the need for automation testing and cross browser testing right away from the table. The only part we need to test before sending the email is whether the template gets delivered as we intend it to and in the correct folder. This can be achieved through Litmus.

Litmus comes as a complete solution for emails, including marketing. Litmus testing helps developers and testers view their email in hundreds of email customers and verify their design using tools just a click away.

If you use Litmus for testing Foundation emails, you get the following benefits:

• Preview feature – Litmus lets you preview the email on more than a hundred customers, including dark mode. It will also provide recommendations in the email.
• Spam filtering – Litmus lets you verify whether your email will land in the spam (or junk) folder or regular primary inbox without sending a single email. This is extremely important as people generally do not open or take note of spam emails.

• Automated tests – Litmus will run a series of automated tests on the email template that will automatically test the essential features of the email. These include the links, images, etc.
• Integrations – Litmus also provides support for integrations that help extend testing to other dimensions from within a single spot.

With the combination of Foundation email development and expertise in Litmus, a tester has all the tools for efficient Foundation testing of emails.

Foundation Testing of Web Apps

The web applications developed using Foundation will need a different tactic for testing than that from Litmus.

For this part, we focus on four major components:

• JavaScript unit testing
• Sass unit testing
• Visual regression testing
• Cross browser testing

JavaScript Unit Testing

JavaScript unit testing aims at identifying the issues in the JavaScript part of the application. The test cases should reside inside the test/javascript folder. For this part, Foundation uses Mocha to run tests, Chai for assertions, and Sinon for test spies and stubs.

Sass Unit Testing

Foundation styling is written in Sass, which is flat and raw and provides more room for the developer’s imagination. While JavaScript unit tests focus on the functionality part, Sass unit testing aims at testing the styling part. Foundation uses Mocha for logging the output, and the test cases reside inside the test/sass folder. These are written in True.

Visual Regression Testing

Visual regression testing identifies visual regression tests and is stored inside the test/visual folder. This needs to be created and verified manually using HTML files and reproducing the bug thereupon. All these three testing facilities will be provided along with the other files downloaded for web app development in Foundation.

Cross Browser Testing

The final testing part we need to conduct on the web app is cross browser testing. While the above three types focus on functionality, design, and visual appearance, they do not consider the possibility of an error when the type of system changes. For instance, you might not see an alignment issue in Google Chrome on Windows 11, but see it in Safari on macOS or in an older Chrome version.

Cross browser testing is important but hectic considering the fragmented device world today. Manually, it is quite impossible to achieve this task; therefore, as a tester, it is best to opt for cloud-based testing solutions. The next section explores this possibility with TestMu AI.