Many websites have a dedicated contact form that allows users to send a message to the website owner. Using Cypress, we can easily write automated tests to prevent regressions to these types of forms.

Use case

For this article, we'll use a contact form containing three fields:

• Name
• E-Mail
• Message

Acceptance criteria

Before diving into writing the actual tests, it's usually a good idea to reflect on the acceptance criteria to determine what actually needs to be tested:

• The contact form should be empty by default
• The form can only be submitted if
  • All form fields are filled in
  • The e-mail address field contains a valid e-mail address
• After the form has been successfully submitted
  • The fields should be hidden
  • A message should be shown saying the form was sent successfully
• In case of an http error after submitting the form, an error message should be displayed and the fields should remain visible

Support functions

Based on these acceptance criteria, we can prepare some support functions to implement the desired checks and to make the actual test file more readable and maintainable. These functions can be added in the Cypress test file on top of your actual tests, or you could add them in specific support file.

Retrieving the fields DOM elements

Since our contact form already contains ids for each field, the field elements can easily be retrieved:

type ChainableInputElement = Cypress.Chainable<JQuery<HTMLInputElement>>;

export const getNameField = (): ChainableInputElement => cy.get('#field-Name');
export const getMailField = (): ChainableInputElement => cy.get('#field-Email');
export const getMessageField = (): ChainableInputElement => cy.get('#field-Message');
export const getForm = () => cy.get('form');

The reason we explicitly define the return type for each of the query functions is that by default, cy.get returns a Chainable HTMLElement, which doesn't allow us to chain with other handy functions like type.

Filling out the form

We'll need to be able to fill out the form with some valid dummy values:

export const completeForm = () => {
  getNameField().type('John Doe');
  getMailField().type('john.doe@mail.com');
  getMessageField().type('This is my message');
};

Check validity of fields

The fields are all required so they might throw a validation error valueMissing. On top of that, the e-mail field might throw a typeMismatch validation error if the entered value is not a valid e-mail address.

export const assertValueMissing = (field: ChainableInputElement) => assertValidity(field, { valueMissing: true });

export const assertTypeMismatch = (field: ChainableInputElement) => assertValidity(field, { typeMismatch: true });

const assertValidity = (field: ChainableInputElement, expectedValidity: { valueMissing?: boolean; typeMismatch?: boolean }) =>
  field.invoke('prop', 'validity').should('deep.include', {
    valueMissing: false,
    typeMismatch: false,
    ...expectedValidity,
  });

Form fields visibility

The following function verifies if the fields are visible or hidden:

export const assertFieldsVisible = (visible: boolean) => cy.get('input').should(visible ? 'have.length.gt' : 'have.length', 0);

Mocking the api call

When we submit the form using a POST request in a Cypress test, we don't want to actually send the form data to the api. Instead, we can use intercept to mock the api call and return a specific response.

Note that we store the intercepted call using an alias so that we can easily check later if the data was submitted or not.

const submitAlias = 'submit';

export const mockResponseStatusCode = (statusCode: number) => cy.intercept('POST', 'http://localhost:4200/api/contact', { statusCode }).as(submitAlias);

Checking that the form was submitted

To verify if the form data was submitted, the previously assigned alias can be used:

export const assertSubmitted = (submitted: boolean) => cy.get(`@${submitAlias}`).should(submitted ? 'not.be.null' : 'be.null');

Submitting the form

There is only one button on the page, so we can just click the first button found to submit the form:

export const clickSubmitButton = () => cy.get('button').click();

Implementing the Cypress test

Now that we have all these support functions ready, we can easily implement the actual tests:

describe('contact', () => {
  beforeEach(() => cy.visit('/contact'));

  it('form fields should be empty by default', () => [getNameField(), getMailField(), getMessageField()].forEach((field) => field.should('be.empty')));

  it('form fields should have errors for missing fields', () => {
    assertValueMissing(getNameField());
    assertValueMissing(getMailField());
    assertValueMissing(getMessageField());
  });

  it('email field should have an error for an incorrect email address', () => {
    getMailField().type('john.doe@');
    assertTypeMismatch(getMailField());
  });

  describe('when submitting an invalid form', () => {
    beforeEach(() => {
      mockResponseStatusCode(204);
      clickSubmitButton();
    });
    it('should not send a POST request to the APi', () => assertSubmitted(false));
    it('should keep the fields visible', () => assertFieldsVisible(true));
  });

  describe('when submitting a valid form', () => {
    beforeEach(() => {
      completeForm();
      mockResponseStatusCode(204);
      clickSubmitButton();
    });
    it('should send a POST request to the APi', () => assertSubmitted(true));
    it('should display a success message', () => getForm().should('contain', 'Message succesfully sent, thank you!'));
    it('should hide the form fields', () => assertFieldsVisible(false));
  });

  describe('when submitting a valid form returns an error response', () => {
    beforeEach(() => {
      completeForm();
      mockResponseStatusCode(400);
      clickSubmitButton();
    });
    it('should send a POST request to the APi', () => assertSubmitted(true));
    it('should display an error message', () => getForm().should('contain', 'Something went wrong, try again later.'));
    it('should keep the fields visible', () => assertFieldsVisible(true));
  });
});

Summary

In this article, we demonstrated how to implement automated testing for a simple contact form using Cypress.

We first defined some acceptance criteria determining the requirements for the contact form. Based on these acceptance criteria, a number of support functions were implemented to keep the final test file more readable and maintainable. Finally, these support functions were used in the actual test file.

Angular Material provides a MatDialogService that allows developers to easily integrate modal dialogs into their applications. If you're not familiar with Angular Material or its dialog service, check out the official documentation.

While this dialog service is very easy to use, the interaction between the MatDialogService and your dialog component isn't completely type-safe and could potentially lead to runtime issues.

Use case

Our use case is using Angular v17.0.4 and is based on this example in the official Angular Material documentation.

The dialog receives an input object representing a favorite animal:

export interface DialogData {
  animal: string;
}

It then displays the animals in a dialog and asks the user to cancel or approve:

After clicking one of the buttons, the dialog returns a boolean representing the button that was clicked.

Implementation

Parent component

<!--template-->
<button mat-button (click)="openDialog()">Open dialog</button>

@Component({
  selector: 'app-component',
  // template: see above
})
export class AppComponent {
  private dialog = inject(DialogService);

  protected openDialog() {
    this.dialog
      .open(DialogComponent, { data: { animal: 'panda' } })
      .afterClosed()
      .pipe(tap((result) => console.log(result === true)))
      .subscribe();
  }
}

Dialog component

<!--template-->
<h1 mat-dialog-title>Favorite Animal</h1>
<mat-dialog-content>
  <p>My favorite animal is "{{ data.animal }}".</p>
  <p>Do you approve?</p>
</mat-dialog-content>
<mat-dialog-actions>
  <button mat-button (click)="cancelClick()">Cancel</button>
  <button mat-button (click)="okClick()">Ok</button>
</mat-dialog-actions>

@Component({
  selector: 'example-dialog',
  // template: see above
})
export class DialogComponent {
  protected data: DialogData = inject(MAT_DIALOG_DATA);
  protected dialogRef: MatDialogRef<DialogComponent> = inject(MatDialogRef);

  protected cancelClick = () => this.dialogRef.close(false);
  protected okClick = () => this.dialogRef.close(true);
}

Type safety issues

While the dialog in our use case is currently working perfectly fine, the interaction between the parent and the dialog component is not completely type-safe.

Let's identify some possible issues that will still compile completely fine, but that would break at runtime.

Parent component

• When opening the dialog, a typo could be made in the animal property name that is passed as the dialog data:

this.dialog.open(DialogComponent, { data: { annimal: 'panda' } });

• The parent component receives an untyped result from the afterClosed operator that could be used in a wrong way:

this.dialog
  .open(DialogComponent, { data: { animal: 'panda' } })
  .afterClosed()
  // this will always log false, since result is a boolean
  .pipe(tap((result) => console.log(result === 'true')))
  .subscribe();

Dialog component

• In the dialog component we might have forgotten about the correct type we were going to use and use a wrong type instead:

protected data: { favouriteAnimal: string } = inject(MAT_DIALOG_DATA);

• The dialog should return a boolean value after closing, but nothing currently prevents us from passing anything else when closing the dialog:

this.dialogRef.close('cancel');

Parent-child type synchronization

There is no synchronization between the Data and Result types used in the parent component and the dialog component. This means the application will still compile when we use different types by mistake on both sides.

Adding generic params

A first step towards more type-safety would be to explicitly specify the types in the parent component when opening the dialog:

// parent component
this.dialog
  .open<DialogComponent, DialogData, boolean>(DialogComponent, {
    data: { animal: 'panda' },
  })
  .afterClosed()
  // result: boolean | undefined
  .pipe(tap((result) => console.log(result === true)))
  .subscribe();

In the dialog component, we can force the result type when injecting the MatDialogRef:

// dialog component
protected data: DialogData = inject(MAT_DIALOG_DATA);
protected dialogRef: MatDialogRef<DialogComponent, boolean> = inject(MatDialogRef);

While these simple changes effectively force the developer to use correct dialog data and result objects, it still doesn't prevent using different Data/Result types in the parent and dialog component. It also has the drawback that the types need to be specified in both the parent and child component.

Using an abstract dialog component superclass

To increase type safety even further between the parent and dialog component and have a single source of truth for the dialog Data/Result types, a custom dialog service and abstract dialog component superclass can be created:

@Directive()
export abstract class StronglyTypedDialog<DialogData, DialogResult> {
  protected data: DialogData = inject(MAT_DIALOG_DATA);
  protected dialogRef: MatDialogRef<StronglyTypedDialog<DialogData, DialogResult>, DialogResult> = inject(MatDialogRef);
}

@Injectable({ providedIn: 'root' })
export class DialogService {
  protected dialog = inject(MatDialog);

  open = <DialogData, DialogResult>(component: ComponentType<StronglyTypedDialog<DialogData, DialogResult>>, config?: MatDialogConfig<DialogData>): MatDialogRef<StronglyTypedDialog<DialogData, DialogResult>, DialogResult> => this.dialog.open(component, config);
}

Since the constructor has been moved to an abstract superclass, the dialog component can then be simplified like this:

@Component({
  selector: 'example-dialog',
  // template: unchanged, see above
})
export class DialogComponent extends StronglyTypedDialog<DialogData, boolean> {
  protected cancelClick = () => this.dialogRef.close(false);
  protected okClick = () => this.dialogRef.close(true);
}

The dialog can then be opened through this new DialogService instead of the regular MatDialog service:

@Component({
  selector: 'app-component',
  // template: unchanged, see above
})
export class AppComponent {
  private dialog = inject(DialogService);

  protected openDialog() {
    this.dialog
      .open(DialogComponent, { data: { animal: 'panda' } })
      .afterClosed()
      // result: boolean | undefined
      .pipe(tap((result) => console.log(result === true)))
      .subscribe();
  }
}

This will achieve full type-safety on both the parent and dialog component while making the DialogComponent the single source of truth for the Data/Result types.

Summary

We explored multiple possible runtime issues when using Angular Material dialogs:

• passing unexpected data into the dialog
• returning unexpected results from the dialog to the parent component
• using different data/result types in the parent and dialog component

Some of the issues can be addressed by adding generic params:

• in the function call that opens the dialog
• to the injected MatDialogRef in the dialog constructor

Finally, the open() method of the MatDialogService can be wrapped in a custom service that provides full type-safety and addresses all of the explored issues.

More information

• Example repository
• Official documentation

I've come across various forums (FreakTab, ArcTablet and Tablette-Chinoise) full of people complaining about the same issues. The problem seems to be caused by bad placement and bad insulation of the internal WiFi antenna.

Various solutions were proposed:

• Removing the grounding wire that touches the WiFi antenna and its wire
• Replacing the grounding wire and the WiFi antenna's wire by (better) shielded wires, using wires from old USB cables (involves soldering)
• Isolating the WiFi antenna and its wire by using insulating tape (see instruction video)

I'm not very experienced with soldering and I didn't really like removing ground wires (they're there for a reason, right?), so I went for the last method.

I carefully opened my tablet using guitar plectra to put between the screen and the back case. The guy in the video does it with plastic cards, but I couldn't find anything like that. The WiFi antenna turns out to be the black plastic thing glued to the case at the top right. I carefully unglued it by using a screwdriver and I cutted some pieces of cardboard to put underneath the antenna. I then stabilized these pieces of cardboard with some insulation tape, glued the antenna on it and covered the antenna and its wire with a few more layers of insulating tape.

After wrapping it all back together, I rebooted the tablet and the WiFi connection now seems to be much more stable. No more disconnects and usually more than 50Mbps where I had like 10Mbps before. I can't believe these tablets are sold with such a design failure. I guess that's what you get when buying cheap chinese electronics, right? ;-)

To provide the actual storage, I bought myself this Seagate Expansion 3TB hard drive. I chose to install Raspbian as OS, as it seemed to be the obvious choice in terms of performance.

Raspberry Pi as NAS

While the Pi's specifications won't allow you to build the most powerful NAS in the world, it still has a lot of advantages.

Advantages

• Energy efficient: the pi only uses 2W per hour, so all together this means a yearly cost of €5. Of course you need to add to that the energy usage of the external hard drive, which in my case is something like 9W. In total this means a yearly cost of of +/- €20. This is far less than any other NAS system.
• Low noise: the pi does not make any noise, so you only need to worry about the external hard drive's noise
• Cheap: pi's are available at around €40, a simple case costs €10 so for +/- €50 you have your NAS system
• Small: the pi is a pocket-size computer, so it fits anywhere.

Disadvantages

• USB 2.0: while my external hard drive has a USB 3-0 port, the pi only has 2 USB 2.0 ports. This limits the maximum transfer speed.
• LAN 100Mbps: if your other network devices have gigabit-speed (or better) lan ports, the transfer speed for reading/writing to your raspberry pi NAS will be limited.
• Performance: with 512MB of RAM and a default cpu speed of 700MHz you shouldn't expect any miracles, but overall the performance is acceptable if you're not running too many other cpu consuming applications on it

Truecrypt

I started by formatting and encrypting my external drive on my Ubuntu box. I chose ext4 as filesystem. Then I connected the drive to my Raspberry Pi, using one of the 2 USB ports.

In the meantime I found this post by Reinhard Seiler, telling that Truecrypt doesn't come precompiled for the Raspberry Pi, so I needed to either compile it myself or use the compiled binary available on his blog. So I downloaded the binary from his blog and tried to mount my drive using the compiled Truecrypt binary. Raspbian does not provide some necessary kernel modules for encryption, so you need to use the flag -m=nokernelcrypto to use truecrypt encryption on the Raspberry.

That was when I ran into the following error message.

Error: The drive uses a sector size other than 512 bytes.

Due to limitations of components available on your platform, partition/device-hosted volumes cannot be created/used on the drive.

Possible solutions:

• Create a file-hosted volume (container) on the drive.
• Use a drive with 512-byte sectors.
• Use TrueCrypt on another platform.

So apparently Truecrypt on Linux doesn't support hard drives with a sector size other than 512 bytes while my brand new external hard drive had a sector size of 4Kb which seems to be the new standard for recent hard drives. The same error appeared when mounting on my Ubuntu box, so it had to be a Truecrypt issue.

I then stumbled upon this post by a guy who ran into the same problem on Mac OSX. He eventually got it working by digging around in the code and compiling his own custom version of Truecrypt. This post by Karl Herrick describes well how to compile Truecrypt on the Raspberry Pi, so I decided to take a look into Truecrypt's source code to eventually correct the issue and compile my own Truecrypt binary as well.

I downloaded the source code for Truecrypt 7.1a and I eventually found the following section in the file Core/Unix/CoreUnix.cpp on line 445:

#if defined (TC_LINUX)
  if (volume - > GetSectorSize() != TC_SECTOR_SIZE_LEGACY) {
      if (options.Protection == VolumeProtection::HiddenVolumeReadOnly)
          throw UnsupportedSectorSizeHiddenVolumeProtection();
      if (options.NoKernelCrypto)
          throw UnsupportedSectorSizeNoKernelCrypto();
  }
#endif

So it seems that when we're using the nokernelcrypto flag for mounting truecrypt-encrypted hard drives with sector sizes other than 512bytes, Truecrypt fails by design.

While not having any clue whatsoever as to why this was implemented this way, I commented out these 2 lines as follows:

#if defined(TC_LINUX)
if (volume - & gt; GetSectorSize() != TC_SECTOR_SIZE_LEGACY) {
    if (options.Protection == VolumeProtection::HiddenVolumeReadOnly)
        throw UnsupportedSectorSizeHiddenVolumeProtection();

    //if (options.NoKernelCrypto)
    //throw UnsupportedSectorSizeNoKernelCrypto();
}
#endif

Then I followed the instructions on Karl Herrick's blog post to compile Truecrypt, but there were some errors in his script, so I adapted it as follows:

#get source files other than the TrueCrypt source
sudo wget -P /usr/local/src http://prdownloads.sourceforge.net/wxwindows/wxWidgets-2.8.11.tar.gz
sudo wget -P /usr/local/src/pkcs11 ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v211/pkcs11.h
sudo wget -P /usr/local/src/pkcs11 ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v211/pkcs11f.h
sudo wget -P /usr/local/src/pkcs11 ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v211/pkcs11t.h

#get and install dependent packages
sudo apt-get -y install libgtk2.0-dev libfuse-dev nasm libwxgtk2.8-dev

#extract, configure, and make wxWidgets
sudo tar -xzvf /usr/local/src/wxWidgets-2.8.11.tar.gz -C /usr/local/src
cd /usr/local/src/wxWidgets-2.8.11/
./configure
make

#setup, extract
export PKCS11_INC=/usr/local/src/pkcs11
sudo tar -xzvf /usr/local/src/TrueCrypt\\ 7.1a\\ Source.tar.gz -C /usr/local/src
cd /usr/local/src/truecrypt-7.1a-source

#comment out some lines that prevented building
sed -i 's#TC_TOKEN_ERR (CKR_NEW_PIN_MODE)#/\*TC_TOKEN_ERR (CKR_NEW_PIN_MODE)\*/#g' Common/SecurityToken.cpp
sed -i 's#TC_TOKEN_ERR (CKR_NEXT_OTP)#/\*TC_TOKEN_ERR (CKR_NEXT_OTP)\*/#g' Common/SecurityToken.cpp
sed -i 's#TC_TOKEN_ERR (CKR_FUNCTION_REJECTED)#/\*TC_TOKEN_ERR (CKR_FUNCTION_REJECTED)\*/#g' Common/SecurityToken.cpp

#compile, build, make!
sudo make WX_ROOT=/usr/local/src/wxWidgets-2.8.11/ wxbuild
sudo -E make WXSTATIC=1

echo
echo TrueCrypt should be found in /usr/local/src/truecrypt-7.1a-source/Main/

By using this custom version of Truecrypt, I finally got to mount my drive without any issues and it's still working like a charm after a few months. The drive is operating the way it should and I have not lost any data so far.