open-index/open-npm huggingface dataset:
npm package: @kodekonveyor/cdd-ts
Description: Test-time Contract Development framework for TypeScript
Latest version: 2.3.0

# Test-time Contract Driven Development framework

In formal verification of algorithm we state relationships about and between its inputs, outputs, internal and external states.
The set of those relationships are called contracts.

In TDD, we actually define those contracts with test cases.
Test cases can be thought as the code verifying the contract of a service, by testing it with a representative parameter for all cases of the logic of the service.

To conduct those tests, we need stubs for underlying services; services used by the service under test.
The stubs are also providing information using the representative parameter sets.
Those stubs are code providing the needed information about the contract of the underlying service.

That means that the contract of most of those services are coded more times: once as test cases verifying the service, and one or more times as stubs providing information about the service as an underlying one.

Coding the whole information once have the following advantages:

- less coding effort: the information is coded only once, instead of two or more times
- more structural approach: while there are approaches to make sure that test coverage is adequate, stubs are written in a more or less ad-hoc manner.
  Using the contract for both goals means that the process can use the structured approach of testing.
- integration assurance: as the same code is used for stubs and tests, we know that the information used about an underlying service is actually tested, so the service actually works as the stubs say it should work.

It can be argued that this approach is not actually contract-driven: we are not coding the contract with the mathematical precision needed in algorithm verification, we are still relying on test cases.
In other words we are not defining the contract formally and fully, just pinning it along representative data points.
So maybe the name is not correct. If you have a better name, just tell us.

Existing tools for contract driven development do not concentrate on testing; they either concentrate on

- formal verification; this makes testing unnecessary, but needs very involved work
- run-time verification; as a way to augment formal verification with a less resource-intensive way for less critical parts of the software, and protect the critical parts against forbidden inputs.

This library is a work in progress. For an example of how a contract looks like see the test directory
npm package: @kodekonveyor/inez
Description: Inez is Not Even Zenta
Latest version: 1.0.28

# HelloAppWorld

This project was generated with [Angular CLI](https://github.com/angular/angular-cli) version 15.0.4.

## Development server

Run `ng serve` for a dev server. Navigate to `http://localhost:4200/`. The application will automatically reload if you change any of the source files.

## Code scaffolding

Run `ng generate component component-name` to generate a new component. You can also use `ng generate directive|pipe|service|class|guard|interface|enum|module`.

## Build

Run `ng build` to build the project. The build artifacts will be stored in the `dist/` directory.

## Running unit tests

Run `ng test` to execute the unit tests via [Karma](https://karma-runner.github.io).

## Running end-to-end tests

Run `ng e2e` to execute the end-to-end tests via a platform of your choice. To use this command, you need to first add a package that implements end-to-end testing capabilities.

## Further help

To get more help on the Angular CLI use `ng help` or go check out the [Angular CLI Overview and Command Reference](https://angular.io/cli) page.