Testing

Testing

Software testing is any activity aimed at evaluating an attribute or capability of a program or system and determining that it meets its required results.
Tyree  Becker

Tyree Becker

1656836340

How to Use ReturnValue Configuration Method - Jasmine Testing

Return a single value with the spy using returnValue configuration method - Jasmine Testing. In this video we will see how to return a single value with the spy method using returnValue config method - Jasmine Testing.

GitHub: https://github.com/leelanarasimha

#testing #javascript #jasmine 

How to Use ReturnValue Configuration Method - Jasmine Testing
Tyree  Becker

Tyree Becker

1656749700

How to Call Customized Functionality for A Spy Method using callFake

Call customized functionality for a spy method using callFake - Jasmine Testing. In this video we will see how to call the customized logic by replacing the original functionality using callFake - Jasmine Testing.

GitHub: https://github.com/leelanarasimha

#testing #javascript #jasmine 

How to Call Customized Functionality for A Spy Method using callFake
Tyree  Becker

Tyree Becker

1656659640

How to Call The Implementation Of The Spy Function using callThrough

Call the implementation of the spy function using callThrough - Jasmine Testing. In this video we will see the how to call the actual; implementation of the spy method using the callThrough - Jasmine Testing.

GitHub: https://github.com/leelanarasimha

#testing #javascript #jasmine 

How to Call The Implementation Of The Spy Function using callThrough
Tyree  Becker

Tyree Becker

1656575760

How to Spy on The Remaining Methods Multiply - Jasmine Testing

Spying on the methods multiply, divide and subtract calculator prototypes - Jasmine Testing. In this video we will see how to spy on the remaining methods multiply, divide and subtract calculator prototypes - Jasmine Testing.

GitHub: https://github.com/leelanarasimha

#testing #javascript #jasmine 

How to Spy on The Remaining Methods Multiply - Jasmine Testing
Tyree  Becker

Tyree Becker

1656484260

How to Spy on The Prototypes using spyOn Method - Jasmine Testing

Spying on the prototypes using spyOn method - Jasmine Testing. In this video we will see how to spy on the prototypes using spyOn method - Jasmine Testing.

GitHub: https://github.com/leelanarasimha

#testing #javascript #jasmine 

How to Spy on The Prototypes using spyOn Method - Jasmine Testing
Tyree  Becker

Tyree Becker

1656397800

Learn About The Spy Matcher toHaveBeenCalledTimes in Jasmine Spies

ToHaveBeenCalledTimes Matcher in Jasmine Spies - Jasmine Testing. In this video we will see about the spy matcher toHaveBeenCalledTimes in Jasmine Spies - Jasmine Testing.

GitHub: https://github.com/leelanarasimha

#testing #javascript #jasmine 

Learn About The Spy Matcher toHaveBeenCalledTimes in Jasmine Spies
Edward Jackson

Edward Jackson

1656385693

Test Driven Development (TDD): The Real Reason to Choose It

TDD - It's About More Than Just the Tests

Test driven development is all the rage. But why do people choose to write their code in a test driven fashion? It’s so their code will have tests, right? Ending up with tested code is a nice benefit of test driven development (TDD), but it’s not the most compelling reason to choose TDD. The real reason to choose TDD is because it helps you write better code. Simpler, more elegant code that’s easier to maintain and has fewer bugs. Who doesn’t want that?

In this session we’ll do a live coding demo showing how TDD works in action. We’ll see the basic mechanics of TDD, and we’ll also see how TDD helps us break apart the problem into solvable chunks and end up with a solution that is simpler and more elegant than we might have arrived at without TDD.

If you aren’t super familiar with TDD and want to see how it works and how it can help make your code better, this session is for you.


What is Test Driven Development (TDD)

Test Driven Development (TDD) is software development approach in which test cases are developed to specify and validate what the code will do. In simple terms, test cases for each functionality are created and tested first and if the test fails then the new code is written in order to pass the test and making code simple and bug-free.

Test-Driven Development starts with designing and developing tests for every small functionality of an application. TDD framework instructs developers to write new code only if an automated test has failed. This avoids duplication of code. The TDD full form is Test-driven development.

Test Driven Development (TDD): Learn with Example

The simple concept of TDD is to write and correct the failed tests before writing new code (before development). This helps to avoid duplication of code as we write a small amount of code at a time in order to pass tests. (Tests are nothing but requirement conditions that we need to test to fulfill them).

Test-Driven development is a process of developing and running automated test before actual development of the application. Hence, TDD sometimes also called as Test First Development.

How to perform TDD Test

Following steps define how to perform TDD test,

  1. Add a test.
  2. Run all tests and see if any new test fails.
  3. Write some code.
  4. Run tests and Refactor code.
  5. Repeat.

 

 

Five Steps of Test-Driven Development

 

Five Steps of Test-Driven Development


TDD cycle defines

  1. Write a test
  2. Make it run.
  3. Change the code to make it right i.e. Refactor.
  4. Repeat process.

Some clarifications about TDD:

  • TDD approach is neither about “Testing” nor about “Design”.
  • TDD does not mean “write some of the tests, then build a system that passes the tests.
  • TDD does not mean “do lots of Testing.”

TDD Vs. Traditional Testing

Below is the main difference between Test driven development and traditional testing:

TDD approach is primarily a specification technique. It ensures that your source code is thoroughly tested at confirmatory level.

  • With traditional testing, a successful test finds one or more defects. It is same as TDD. When a test fails, you have made progress because you know that you need to resolve the problem.
  • TDD ensures that your system actually meets requirements defined for it. It helps to build your confidence about your system.
  • In TDD more focus is on production code that verifies whether testing will work properly. In traditional testing, more focus is on test case design. Whether the test will show the proper/improper execution of the application in order to fulfill requirements.
  • In TDD, you achieve 100% coverage test. Every single line of code is tested, unlike traditional testing.
  • The combination of both traditional testing and TDD leads to the importance of testing the system rather than perfection of the system.
  • In Agile Modeling (AM), you should “test with a purpose”. You should know why you are testing something and what level its need to be tested.

What is acceptance TDD and Developer TDD

There are two levels of TDD

  1. Acceptance TDD (ATDD): With ATDD you write a single acceptance test. This test fulfills the requirement of the specification or satisfies the behavior of the system. After that write just enough production/functionality code to fulfill that acceptance test. Acceptance test focuses on the overall behavior of the system. ATDD also was known as Behavioral Driven Development (BDD).
  2. Developer TDD: With Developer TDD you write single developer test i.e. unit test and then just enough production code to fulfill that test. The unit test focuses on every small functionality of the system. Developer TDD is simply called as TDD.The main goal of ATDD and TDD is to specify detailed, executable requirements for your solution on a just in time (JIT) basis. JIT means taking only those requirements in consideration that are needed in the system. So increase efficiency.

Test Driven Development (TDD): Learn with Example

Scaling TDD via Agile Model Driven Development (AMDD)

TDD is very good at detailed specification and validation. It fails at thinking through bigger issues such as overall design, use of the system, or UI. AMDD addresses the Agile scaling issues that TDD does not.

Thus AMDD used for bigger issues.

The lifecycle of AMDD

Test Driven Development (TDD): Learn with Example

In Model-driven Development (MDD), extensive models are created before the source code is written. Which in turn have an agile approach?

In above figure, each box represents a development activity.

Envisioning is one of the TDD process of predicting/imagining tests which will be performed during the first week of the project. The main goal of envisioning is to identify the scope of the system and architecture of the system. High-level requirements and architecture modeling is done for successful envisioning.

It is the process where not a detailed specification of software/system is done but exploring the requirements of software/system which defines the overall strategy of the project.

Iteration 0: Envisioning

There are two main sub-activates.

  1. Initial requirements envisioning.It may take several days to identify high-level requirements and scope of the system. The main focus is to explore usage model, Initial domain model, and user interface model (UI).
  2. Initial Architectural envisioning. It also takes several days to identify architecture of the system. It allows setting technical directions for the project. The main focus is to explore technology diagrams, User Interface (UI) flow, domain models, and Change cases.

Iteration modeling

Here team must plan the work that will be done for each iteration.

  • Agile process is used for each iteration, i.e. during each iteration, new work item will be added with priority.
  • First higher prioritized work will be taken into consideration. Work items added may be reprioritized or removed from items stack any time.
  • The team discusses how they are going to implement each requirement. Modeling is used for this purpose.
  • Modeling analysis and design is done for each requirement which is going to implement for that iteration.

Model storming

This is also known as Just in time Modeling.

  • Here modeling session involves a team of 2/3 members who discuss issues on paper or whiteboard.
  • One team member will ask another to model with them. This modeling session will take approximately 5 to 10 minutes. Where team members gather together to share whiteboard/paper.
  • They explore issues until they don’t find the main cause of the problem. Just in time, if one team member identifies the issue which he/she wants to resolve then he/she will take quick help of other team members.
  • Other group members then explore the issue and then everyone continues on as before. It is also called as stand-up modeling or customer QA sessions.

Test Driven Development (TDD)

  • It promotes confirmatory testing of your application code and detailed specification.
  • Both acceptance test (detailed requirements) and developer tests (unit test) are inputs for TDD.
  • TDD makes the code simpler and clear. It allows the developer to maintain less documentation.

Reviews

  • This is optional. It includes code inspections and model reviews.
  • This can be done for each iteration or for the whole project.
  • This is a good option to give feedback for the project.

Test Driven Development (TDD) Vs. Agile Model Driven Development (AMDD)

TDDAMDD
  • TDD shortens the programming feedback loop
  • AMDD shortens modeling feedback loop.
  • TDD is detailed specification
  • AMDD works for bigger issues
  • TDD promotes the development of high-quality code
  • AMDD promotes high-quality communication with stakeholders and developers.
  • TDD speaks to programmers
  • AMDD talks to Business Analyst, stakeholders, and data professionals.
  • TDD non-visually oriented
  • AMDD visually oriented
  • TDD has limited scope to software works
  • AMDD has a broad scope including stakeholders. It involves working towards a common understanding
  • Both support evolutionary development
——————————————–

Now, let’s learn Test Driven Development by example.

Example of TDD

Here in this Test Driven Development example, we will define a class password. For this class, we will try to satisfy following conditions.

A condition for Password acceptance:

  • The password should be between 5 to 10 characters.

First in this TDD example, we write the code that fulfills all the above requirements.

Test Driven Development (TDD): Learn with Example

Scenario 1: To run the test, we create class PasswordValidator ();

Test Driven Development (TDD): Learn with Example

We will run above class TestPassword ();

Output is PASSED as shown below;

Output:

Test Driven Development (TDD): Learn with Example

Scenario 2: Here we can see in method TestPasswordLength () there is no need of creating an instance of class PasswordValidator. Instance means creating an object of class to refer the members (variables/methods) of that class.

Test Driven Development (TDD): Learn with Example

We will remove class PasswordValidator pv = new PasswordValidator () from the code. We can call the isValid () method directly by PasswordValidator. IsValid (“Abc123”). (See image below)

So we Refactor (change code) as below:

Test Driven Development (TDD): Learn with Example

Scenario 3: After refactoring the output shows failed status (see image below) this is because we have removed the instance. So there is no reference to non –static method isValid ().

Test Driven Development (TDD): Learn with Example

So we need to change this method by adding “static” word before Boolean as public static boolean isValid (String password). Refactoring Class PasswordValidator () to remove above error to pass the test.

Test Driven Development (TDD): Learn with Example

Output:

After making changes to class PassValidator () if we run the test then the output will be PASSED as shown below.

Test Driven Development (TDD): Learn with Example

Advantages of TDD

Following are the main advantages of Test Driven Development in Software Engineering:

  • Early bug notification.
  • Developers test their code but in the database world, this often consists of manual tests or one-off scripts. Using TDD you build up, over time, a suite of automated tests that you and any other developer can rerun at will.
  • Better Designed, cleaner and more extensible code.
  • It helps to understand how the code will be used and how it interacts with other modules.
  • It results in better design decision and more maintainable code.
  • TDD allows writing smaller code having single responsibility rather than monolithic procedures with multiple responsibilities. This makes the code simpler to understand.
  • TDD also forces to write only production code to pass tests based on user requirements.
  • Confidence to Refactor
  • If you refactor code, there can be possibilities of breaks in the code. So having a set of automated tests you can fix those breaks before release. Proper warning will be given if breaks found when automated tests are used.
  • Using TDD, should results in faster, more extensible code with fewer bugs that can be updated with minimal risks.
  • Good for teamwork
  • In the absence of any team member, other team members can easily pick up and work on the code. It also aids knowledge sharing, thereby making the team more effective overall.
  • Good for Developers
  • Though developers have to spend more time in writing TDD test cases, it takes a lot less time for debugging and developing new features. You will write cleaner, less complicated code.

#testing #softwaretesting

Test Driven Development (TDD): The Real Reason to Choose It
Garry Taylor

Garry Taylor

1656302389

Playwright: A Framework for Web Testing and Automation

🎭 Playwright

Playwright is a framework for Web Testing and Automation. It allows testing Chromium, Firefox and WebKit with a single API. Playwright is built to enable cross-browser web automation that is ever-green, capable, reliable and fast.

Headless execution is supported for all the browsers on all platforms. Check out system requirements for details.

Looking for Playwright for Python, .NET, or Java?

Installation

Playwright has its own test runner for end-to-end tests, we call it Playwright Test.

Using init command

The easiest way to get started with Playwright Test is to run the init command.

# Run from your project's root directory
npm init playwright@latest
# Or create a new project
npm init playwright@latest new-project

This will create a configuration file, optionally add examples, a GitHub Action workflow and a first test example.spec.ts. You can now jump directly to writing assertions section.

Manually

Add dependency and install browsers.

npm i -D @playwright/test
# install supported browsers
npx playwright install

You can optionally install only selected browsers, see install browsers for more details. Or you can install no browsers at all and use existing browser channels.

Capabilities

Resilient • No flaky tests

Auto-wait. Playwright waits for elements to be actionable prior to performing actions. It also has rich set of introspection events. The combination of the two eliminate the need for artificial timeouts - primary cause of flaky tests.

Web-first assertions. Playwright assertions are created specifically for the dynamic web. Checks are automatically retried until the necessary conditions are met.

Tracing. Configure test retry strategy, capture execution trace, videos, screenshots to eliminate flakes.

No trade-offs • No limits

Browsers run web content belonging to different origins in different processes. Playwright is aligned with the modern browsers architecture and runs tests out-of-process. This makes Playwright free of the typical in-process test runner limitations.

Multiple everything. Test scenarios that span multiple tabs, multiple origins and multiple users. Create scenarios with different contexts for different users and run them against your server, all in one test.

Trusted events. Hover elements, interact with dynamic controls, produce trusted events. Playwright uses real browser input pipeline indistinguishable from the real user.

Test frames, pierce Shadow DOM. Playwright selectors pierce shadow DOM and allow entering frames seamlessly.

Full isolation • Fast execution

Browser contexts. Playwright creates a browser context for each test. Browser context is equivalent to a brand new browser profile. This delivers full test isolation with zero overhead. Creating a new browser context only takes a handful of milliseconds.

Log in once. Save the authentication state of the context and reuse it in all the tests. This bypasses repetitive log-in operations in each test, yet delivers full isolation of independent tests.

Powerful Tooling

Codegen. Generate tests by recording your actions. Save them into any language.

Playwright inspector. Inspect page, generate selectors, step through the test execution, see click points, explore execution logs.

Trace Viewer. Capture all the information to investigate the test failure. Playwright trace contains test execution screencast, live DOM snapshots, action explorer, test source and many more.

Looking for Playwright for TypeScript, JavaScript, Python, .NET, or Java?

Examples

To learn how to run these Playwright Test examples, check out our getting started docs.

Page screenshot

This code snippet navigates to whatsmyuseragent.org and saves a screenshot.

import { test } from '@playwright/test';

test('Page Screenshot', async ({ page }) => {
  await page.goto('http://whatsmyuseragent.org/');
  await page.screenshot({ path: `example.png` });
});

Mobile and geolocation

This snippet emulates Mobile Safari on a device at a given geolocation, navigates to maps.google.com, performs action and takes a screenshot.

import { test, devices } from '@playwright/test';

test.use({
  ...devices['iPhone 13 Pro'],
  locale: 'en-US',
  geolocation: { longitude: 12.492507, latitude: 41.889938 },
  permissions: ['geolocation'],
})

test('Mobile and geolocation', async ({ page }) => {
  await page.goto('https://maps.google.com');
  await page.locator('text="Your location"').click();
  await page.waitForRequest(/.*preview\/pwa/);
  await page.screenshot({ path: 'colosseum-iphone.png' });
});

Evaluate in browser context

This code snippet navigates to example.com, and executes a script in the page context.

import { test } from '@playwright/test';

test('Evaluate in browser context', async ({ page }) => {
  await page.goto('https://www.example.com/');
  const dimensions = await page.evaluate(() => {
    return {
      width: document.documentElement.clientWidth,
      height: document.documentElement.clientHeight,
      deviceScaleFactor: window.devicePixelRatio
    }
  });
  console.log(dimensions);
});

Intercept network requests

This code snippet sets up request routing for a page to log all network requests.

import { test } from '@playwright/test';

test('Intercept network requests', async ({ page }) => {
  // Log and continue all network requests
  await page.route('**', route => {
    console.log(route.request().url());
    route.continue();
  });
  await page.goto('http://todomvc.com');
});

Resources

Documentation | API reference

Download Details: 
Author: Microsoft
Source Code: https://github.com/Microsoft/playwright 
License: Apache-2.0 license
#playwright #test #testing 

Playwright: A Framework for Web Testing and Automation

What is Playwright Test | How to use Playwright Test to Run Unit Tests

A comparison of Playwright's new test runner versus 'traditional' approaches like Jest and Mocha

Playwright is a framework for Web Testing and Automation. It allows testing Chromium, Firefox and WebKit with a single API. Playwright is built to enable cross-browser web automation that is ever-green, capable, reliable and fast.

Why you might want to use Playwright Test as a test runner for unit tests, and how to fill in missing pieces (e.g. code coverage).

In this blog post, I want to

  • describe what I like about Playwright and why I think it can be a good choice for unit testing
  • outline things missing from Playwright compared to other test frameworks (and how to fill some of those gaps)
  • suggest some minor tweaks to make Playwright more suitable for unit tests

Why to use Playwright Test for unit tests

I had used "traditional" test runners before, mainly Jest, but also Mocha a few years ago.
I think there are some advantages of using Playwright for unit tests:

Same tool for E2E tests and unit tests: One tool less in your setup means one tool less to learn, configure, update, etc.

Out-of-the-box support for TypeScript: Playwright Test supports TypeScript out-of-the-box.
For all other test runners I am aware of you have to configure some transform (Babel, ts-jest, etc.), or run the test runner with ts-node, or compile the test cases before running them (see e.g. "Using Typescript" of the Jest docs).

Access to features unique to Playwright: Playwright has some very useful features, e.g.:

"fixtures" allow to prepare resources per test case on an "opt-in" basis.
This is in my opinion much better than the beforeEach / afterEach fiddling you have to do with other test runners.

// base.ts
import { test as base } from '@playwright/test';
import * as sinon from 'sinon';

export const test = base.extend<{ fakeClock: sinon.SinonFakeTimers }>({
  fakeClock: [
    async ({}, use) => {
      const clock = sinon.useFakeTimers();
      await use(clock);
      clock.restore();
    },
    { scope: 'test' },
  ],
});

// FILE: bar.spec.ts
import { test } from './base';

test('with real clock', ({}) => {
  /*
   * this test case does not use the "fakeClock" fixture,
   * thus the fixture does not get set up
   */
});
test('with fake clock', ({ fakeClock }) => {
  /*
   * fake timers will get set up for this test case
   * because "fakeClock" fixture is used
   */
});

"projects" allow to run "the same or different tests in multiple configurations".
For example a while ago I had to make sure that some client/server interaction based on socket.io works with both WebSockets and HTTP long-polling.
Setting up two Playwright projects with different project parameters allowed me to run the same tests with two configurations, once using WebSockets and once using HTTP long-polling:

// playwright.config.ts
import { PlaywrightTestConfig } from '@playwright/test';

interface TestOptions {
  transport: 'websocket' | 'polling';
}

const config: PlaywrightTestConfig<TestOptions> = {
  projects: [
    {
      name: 'using transport: websocket',
      use: { transport: 'websocket' },
    },
    {
      name: 'using transport: polling',
      use: { transport: 'polling' },
    },
  ],
};

export default config;

// FILE: bar.spec.ts
import { test } from '@playwright/test';

test('socket.io connection', ({ transport }) => {
  /*
   * this test case will get run twice,
   * with "transport" set once to "websocket" and once to "polling"
   */
  initializeSocket(transport);
  // ...
});

Development funded by a big company: Playwright is a product of Microsoft and has been maintained very actively over the last couple of years.

No use of globals: Playwright does not use any globals for its test runner. You import from @playwright/test just what you need in your test files:

// FILE bar.spec.ts
import { expect, test } from '@playwright/test';

test.describe('describe title', () => {
  test('test title', ({}) => {
    expect(1 + 1).toEqual(2);
  });
});

Compare that to existing test runners like Jest and Mocha (and Cypress, using Mocha under-the-hood). Those test runners set up their test functions as globals (it, expect, describe, beforeEach etc.).
In TypeScript projects, as soon as you install any two of these test libraries you end up with TypeScript compilation errors, since the types of those functions are usually not compatible with each other. There are a couple of workarounds to avoid those compilation errors, for example fiddling with (multiple) tsconfig.json files such that types of these libraries are excluded.
Cypress even has a guide dedicated to this problem (docs.cypress.io/guides/tooling/typescript-support#Clashing-types-with-Jest).

Having the same import statements from @playwright/test in every test file might be some boilerplate, but I think the reduced friction (by not having any globals) justifies that boilerplate.
Newer test runners like vitest also do not set globals anymore.

Things missing from Playwright (and how to fill the gaps)

Compared to Jest, there are some things missing from Playwright Test which are often needed when running unit tests.
Most of those things can be substituted by using libraries of the Node.js ecosystem.
Take a look at the example repository I made to see how to set up those things!

For Mocks & Spies use sinon or jest-mock (the mocking solution shipped with Jest).

For Fake timers use sinon (See code changes).

Code coverage just needs a simple combination of the command-line interface nyc of Istanbul (a code coverage tool for JavaScript) and source-map-support (See code changes).

Watch mode is not supported but "planned work" at the time of writing: playwright.dev/docs/test-components#planned-work.
There are some workarounds in the related issue: github.com/microsoft/playwright/issues/7035.

Some test frameworks provide a way to mock CommonJS/ECMAScript modules.
Module mocking allows to replace the "thing" returned by require/import statements by some fake instance.

Unfortunately, this is not possible in Playwright. Although there are some Node.js libraries that allow module mocking (like testdouble), they don't work because Playwright does some of the module loading itself (github.com/microsoft/playwright/issues/14398).
If you want to get module mocking support in Playwright, you can upvote this feature request: github.com/microsoft/playwright/issues/14572.

This is the biggest downside of using Playwright for unit tests in my opinion.
For now, if you want to test modules isolated from others you probably have to adapt the codebase to use some kind of dependency injection. Be it that dependencies are just passed as arguments when calling functions, or using a dependency injection solution like NestJS IoC containers (which I have used very successfully in the past).

One last thing

Playwright Test has a method expect(...).toMatchSnapshot(...) which can perform snapshot-comparisons on screenshots but also textual and binary data.

At the time of writing, Playwright will append a platform-specific suffix (like linux) to the name of the file the snapshot is stored in. This makes sense for screenshots (since screenshots taken on different platforms will deviate slightly, for example because of text rendering), but it rarely makes sense in case of textual/binary data.

This is an open issue (github.com/microsoft/playwright/issues/11134). An easy workaround is to disable the suffix by setting up an "auto-fixture" and override testInfo.snapshotSuffix:

import { test as base } from '@playwright/test';

export const test = base.extend<{ _autoSnapshotSuffix: void }>({
  _autoSnapshotSuffix: [
    async ({}, use, testInfo) => {
      testInfo.snapshotSuffix = '';
      await use();
    },
    { auto: true },
  ],
});

#testing #playwright #test 

What is Playwright Test | How to use Playwright Test to Run Unit Tests
Tyree  Becker

Tyree Becker

1656300540

Learn About The toHaveBeenCalledwith Matcher in Jasmine Spies

ToHaveBeenCalledWith Matcher in Jasmine Spies - Jasmine Testing. In this video we will see about the toHaveBeenCalledWith matcher in Jasmine Spies - Jasmine Testing.

GitHub: https://github.com/leelanarasimha

#testing #javascript #jasmine 

Learn About The toHaveBeenCalledwith Matcher in Jasmine Spies
Tyree  Becker

Tyree Becker

1656221220

How to Use The Spy Matcher toHaveBeenCalled in The Jasmine Spec Files

Usage of toHaveBeenCalled spy matcher in Spec file For Jasmine Spies - Jasmine Testing. In this video we will see how to use the spy matcher toHaveBeenCalled in the Jasmine Spec files - Jasmine Testing.

GitHub: https://github.com/leelanarasimha

#testing #javascript #jasmine 

How to Use The Spy Matcher toHaveBeenCalled in The Jasmine Spec Files
Mike  Kozey

Mike Kozey

1656216180

NV_cubit_testing: Cubit Testing Plugin Used By NonVanilla

nv_cubit_testing

Cubit testing plugin used by NonVanilla.

Advantages

Gets rid of global variables (compared to bloc_test):

bloc_test

final initialPage = MaterialPage(name: 'initial', child: Container());
final secondPage = MaterialPage(name: 'second', child: Container());

blocTest<NavigationCubit, Page>(
      'push adds second page',
      build: () => NavigationCubit(initialPage: initialPage),
      act: (navigator) => navigator.push(secondPage),
      expect: () => [initialPage, secondPage],
    );

nv_cubit_testing

test('push adds second page', () async {
    final initialPage = MaterialPage(name: 'initial', child: Container());
    final secondPage = MaterialPage(name: 'second', child: Container());

    final states = await NvCubitTesting.collectCubitStates(
      build: () => NavigationCubit(initialPage: initialPage),
      act: (NavigationCubit navigator) async => navigator.push(secondPage),
    );

    expect(states.last.pages, [initialPage, secondPage]);
});

withState extension

Makes mocking the state (with mockito) easier.

// Instead of
final mockBloc = MockBloc();
when(state).thenAnswer((_) => CubitState());
when(stream).thenAnswer((_) => CubitState());

// We write
final mockBloc = MockBloc();
mockBloc.withState(CubitState());

Installing

Use this package as a library

Depend on it

Run this command:

With Flutter:

 $ flutter pub add nv_cubit_testing

This will add a line like this to your package's pubspec.yaml (and run an implicit flutter pub get):

dependencies:
  nv_cubit_testing: ^0.0.8+1

Alternatively, your editor might support flutter pub get. Check the docs for your editor to learn more.

Import it

Now in your Dart code, you can use:

import 'package:nv_cubit_testing/nv_cubit_testing.dart';

example/README.md

example

Example project for the nv_cubit_testing plugin.

Getting Started

This project is a starting point for a Flutter application.

A few resources to get you started if this is your first Flutter project:

For help getting started with Flutter, view our online documentation, which offers tutorials, samples, guidance on mobile development, and a full API reference.

Author: Nonvanilla-shop
Source Code: https://github.com/nonvanilla-shop/nonvanilla_testing 
License: BSD-3-Clause license

#flutter #dart #testing 

NV_cubit_testing: Cubit Testing Plugin Used By NonVanilla
Mike  Kozey

Mike Kozey

1656203100

Coverde: A Set Of Commands for Coverage Tracefiles Manipulation

Coverde

A CLI for basic coverage trace files manipulation.


Installing

You can make coverde globally available by executing the following command:

$ dart pub global activate coverde

NOTE: To run coverde directly from the terminal, add the system cache bin directory to your PATH environment variable.


Features

coverde check

Check coverage value computed from a trace file.

Parameters

OrderDescriptionRequired
Unique parameterAn integer between 0 and 100 used as minimum acceptable coverage value.

Options

OptionDescriptionDefault value
--input
-i
Trace file used for the coverage check.coverage/lcov.info

Flags

FlagDescriptionDefault value
Enable:
--verbose
-v
Disable:
--no-verbose
Print coverage value.Enabled

Examples

  • coverde check 90
  • coverde check 75 -i lcov.info
  • coverde check 100 --no-verbose

Results

Check example (pass)

Check example (fail)

coverde filter

Filter the tested files included in a trace file.

Options

OptionDescriptionDefault value
--input
-i
Coverage trace file to be filtered.coverage/lcov.info
--output
-o
Filtered coverage trace file (automatically created if it is absent).coverage/filtered.lcov.info
--filters
-f
Set of comma-separated patterns of the files to be opted out of coverage. 
--mode
-m
The mode in which the filtered trace file content should be generated.
a: append content.
w: overwrite content.
a (append content)

Examples

  • coverde filter
  • coverde filter -f \.g\.dart
  • coverde filter -f \.freezed\.dart -mode w
  • coverde filter -o coverage/tracefile.info

coverde remove

Remove a set of files and folders.

Flags

FlagDescriptionDefault value
Enable:
--accept-absence
Disable:
--no-accept-absence
Set the command behavior according to a file/folder existence.
If enabled, the command continues and notifies the element absence.
If disabled, the command fails.
Enabled

Examples

  • coverde remove file.txt
  • coverde remove path/to/folder/
  • coverde remove path/to/another.file.txt path/to/another/folder/ local.folder/

coverde report

Generate HTML coverage report.

Options

OptionDescriptionDefault value
--input
-i
Coverage trace file to be used as source for report generation.coverage/lcov.info
--output
-o
Destination folder where the generated report files will be placed.coverage/html/
--mediumMedium threshold for coverage value.75
--highHigh threshold for coverage value.90

The report style is dynamically set according to individual, group and global coverage and the --medium and --high options.

Flags

FlagDescriptionDefault value
Enable:
--launch
-l
Disable:
--no-launch
Launch the generated report in the default browser.Disabled

Examples

  • coverde report
  • coverde report -i coverage/tracefile.info --medium 50
  • coverde report -o coverage/report --high 95 -l

Results

Report example (directory)

Report example (file)

coverde value

Compute and display the coverage value from a trace file.

Options

OptionDescriptionDefault value
--input
-i
Coverage trace file to be used for coverage value computation.coverage/lcov.info

Flags

FlagDescriptionDefault value
Enable:
--verbose
-v
Disable:
--no-verbose
Print coverage value for each source file included by the trace file.Enabled

Examples

  • coverde value
  • coverde value -i coverage/tracefile.info --no-verbose

Usage with melos

If your project uses melos to manage its multi-package structure, it could be handy to collect test coverage data in a unified trace file.

This can be achieved by defining a melos script as follows:

M:
  description: Merge all packages coverage tracefiles ignoring data related to generated files.
  run: >
    coverde rm MELOS_ROOT_PATH/coverage/filtered.lcov.info &&
    melos exec --file-exists=coverage/lcov.info -- coverde filter --input ./coverage/lcov.info --output MELOS_ROOT_PATH/coverage/filtered.lcov.info --filters \.g\.dart

M is the melos script that merges the coverage trace file of all tested packages contained within the project

This melos script ignores generated source files with the .g.dart extension but this behavior could be adjusted by setting the --filters option.

The resulting trace file is the filtered.lcov.info file, located in the coverage folder in the root folder of the project.


CI integration for coverage checks

If your project uses GitHub Actions for CI, you might already know very_good_coverage, which offers a simple but effective method for coverage validation.

However, adding coverage checks to CI workflows hosted by other alternatives is not always that straightforward.

To solve this, after enabling Dart or Flutter in your CI workflow, according to your project requirements, you can use coverde and its check tool by adding the following commands to your workflow steps:

  • dart pub global activate coverde
  • coverde check <min_coverage>

Bugs or Requests

If you encounter any problems or you believe the CLI is missing a feature, feel free to open an issue on GitHub.

Pull request are also welcome. See CONTRIBUTING.md.

Use this package as an executable

Install it

You can install the package from the command line:

dart pub global activate coverde

Use it

The package has the following executables:

$ coverde

Use this package as a library

Depend on it

Run this command:

With Dart:

 $ dart pub add coverde

With Flutter:

 $ flutter pub add coverde

This will add a line like this to your package's pubspec.yaml (and run an implicit dart pub get):

dependencies:
  coverde: ^0.1.0+1

Alternatively, your editor might support dart pub get or flutter pub get. Check the docs for your editor to learn more.

Import it

Now in your Dart code, you can use:

import 'package:coverde/coverde.dart';

example/README.md

Example

# Activate coverde CLI
dart pub global activate coverde

# See list of available commands
coverde --help

Author: mrverdant13
Source Code: https://github.com/mrverdant13/coverde 
License: MIT license

#dart #flutter #testing 

Coverde: A Set Of Commands for Coverage Tracefiles Manipulation

Cakephp-test-helper: CakePHP TestHelper plugin

CakePHP TestHelper plugin

Browser based addons for your test driven development.

Note: This branch is for CakePHP 4.2+. See version map for details.

Motivation

After 2.x=>3.x, the "web-tester" has been removed. It was, for certain cases, however, quite useful. This aims to bring back a part of it.

The CLI also doesn't allow a good overview. Even with auto-complete, you have to type almost everything out. With a browser backend generating tests or running them is just a simple mouse click.

You have an overview of your classes and the test classes to it. If there is one missing, you can easily "bake" it from this web backend. It internally uses Bake plugin as well as your preferred theme.

Further useful addons

  • URL array generation from string URLs (respects routing, so it is basically also a reverse lookup)
  • Fixture validation tool (compares actual DB with the schema files: fields and attributes, constraints and indexes)
  • GUI for fixture comparison and generation of missing ones per mouse click.

Installation

You can install this plugin into your CakePHP application using composer:

composer require --dev dereuromark/cakephp-test-helper

Note: This is not meant for production, so make sure you use the --dev flag and install it as development-only tool.

Setup

Don't forget to load it under your bootstrap function in Application.php:

$this->addPlugin('TestHelper');

This will also load the routes.

Deprecated way

In older applications you used the bootstrap file:

Plugin::load('TestHelper', ['routes' => true]);

Usage

Navigate to /test-helper backend and select the app or plugin you want to check. You can then with a single click

  • check what classes do not yet have a test case
  • generate a test case for them (or copy and paste a generated code into CLI)
  • run test case
  • check coverage on a tested class, as overall and in detail

Supported class types:

  •  Controllers
  •  Models (Tables/Entities)
  •  Components
  •  Behavior
  •  Helpers
  •  Shells
  •  Tasks
  •  Cells
  •  ShellHelpers
  •  Forms
  •  Mailers

Feel free to help out improving and completing this test helper plugin.

Limitations

Executing the tests and coverage from the web backend usually can not work for long running tests due to the timeout issues. Make sure you raise the apache/nginx settings here if you want to use this functionality here.

The focus is on providing an overview and quickly generating the desired classes with a single mouse click.

Author: Dereuromark
Source Code: https://github.com/dereuromark/cakephp-test-helper
License: MIT license

#php #cakephp #testing 

Cakephp-test-helper: CakePHP TestHelper plugin

Demo.Playwright: Various Testing Scenarios with Playwright

🎭 demo.playwright

This repo is used to demo various testing scenarios with Playwright 🎭, using the official test-runner and scripts authored in TypeScript.

The test.yml GitHub Action workflow is used to:

Run Playwright example tests

accessibility - runs accessibility checks against https://www.w3.org

android - runs a basic test using Android's WebView.

basic - basic tests to show interactions, element selectors, assertions, upload files, read a response, mock a response, and page object model (POM).

chrome-extension - basic test that gets a handle to the background page of Chrome extension.

drag-and-drop - runs example drag-and-drop test utilizing https://www.w3schools.com/html/html5_draganddrop.asp.

electron - runs a basic test for Electron application, controlling main electron process and working with Electron window.

fixtures - runs example tests utilizing test and worker fixtures.

github-api - uses GitHub API to test creation of a new repo, bug, and feature, then deletion of repo.

oauth - runs oauth tests for LinkedIn, Facebook, and Google, to login to https://courses.ultimateqa.com/users/sign_in.

performance - web performance tests using resource timing API, DevTools, and lighthouse, run against https://fastestwebsite.net

svgomg - End-to-end tests for SVGOMG! site, hosted at https://demo.playwright.dev/svgomg

todomvc - End-to-end tests for ToDoMVC site, hosted at https://demo.playwright.dev/todomvc

visual-comparison - visually compares snapshots with golden screenshots and text content for playwright.dev landing page.

Publish each HTML report to their respective directory

When the above tests are finished, the results are published to GitHub pages:

Configuration

The baseURL value for most tests is set as a workflow environment variable. This allows flexibility for the URL of the sites tested. By not hardcoding a URL in page.goTo('') we can simply pass baseURL without changing the test script e.g. test.site.com -> stage.site.com -> prod.site.com

Have a testing scenario you'd like to see included?

Please open an issue with details.

Author: MarcusFelling
Source Code: https://github.com/MarcusFelling/Demo.Playwright 
License: Apache-2.0 license

#node #playwright #demo #testing #typescript 

Demo.Playwright: Various Testing Scenarios with Playwright