pact-js
io-ts
Our great sponsors
pact-js | io-ts | |
---|---|---|
9 | 80 | |
1,546 | 6,597 | |
1.4% | - | |
8.7 | 4.9 | |
6 days ago | 5 months ago | |
TypeScript | TypeScript | |
GNU General Public License v3.0 or later | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
pact-js
-
Enhancing Backend Microservices Ecosystem with Contract Testing [Spartans Summit 2024]
First, he shows the official pact.io websites. Then, he clicks on the “View on Github” button by selecting Node JS and Javascript from the list of options.
-
Parsing AWS AppSync Responses, Elm GraphQL Libraries, and Only Doing Front-End
It just just enough abstraction over the basics of converting your HTTP calls to GraphQL queries and mutations, but ALL of the parsing of responses is on you. I’m well versed in parsing JSON in Elm. I’m also familiar with the compiler errors as well as runtime errors you get with JSON that doesn’t match up to what you designed. At some point I’ll probably have to move beyond the unit tests and add contact tests, maybe via Pact.js.
-
The Big TDD Misunderstanding
> I also wasn't aware that "unit" referred to an isolated test, not to the SUT.
I'm with you. That claim is unsubstantiated. It seems to trace to the belief that the first unit tests were XUnit family, thus were SUnit for Scheme. But Kent Beck made it pretty clear that SUnit "units" were classes.
https://web.archive.org/web/20150315073817/http://www.xprogr...
There were unit tests before that. SUnit took its name from common parlance, not vice versa. It was a strange naming convention, given that the unit testing framework could be used to test anything and not just units. Much like the slightly older Test Anything Protocol (TAP) could.
> [on unit tests] This does lead to a lot of work maintaining them whenever the implementation changes, but this is a necessary chore because of the value they provide.
I disagree. Unit tests can still be behavioral. Then they change whenever the behavior changes. They should still work with a mere implementation change.
> This is why I still think that the traditional test pyramid is the best model to follow.
I'll disagree a little with that, too. I think a newer test pyramid that uses contract testing to verify integrations is better. The notion of contract tests is much newer than the pyramids and, properly applied, can speed up feedback by orders of magnitude while also cutting debugging time and maintenance by orders of magnitude.
On that front, I love what Pact is doing and would like to see more competition in the area. Hottest thing in testing since Cypress/Playwright . . .
https://pact.io
-
Ask HN: How do you test your microservices?
I've worked in places where Pact [0] was used for testing services developed by different teams (external) and teams themselves (internal)
[0] https://pact.io/
-
A response to James Shore's Nullable pattern
I'd never heard anyone call those "integrity tests" before. I think "contract test" is more common.
Assuming I understood you, that is.
I've been telling everyone to look at Pact to make contract testing easier to organize and maintain and to make it easier to trigger in the other tests in CI when an interface's behavior changes. They haven't offered me a commission yet. ;-)
https://pact.io
- Gestionarea DTO-urilor intr-o arhitectura de tip Microservicii cu Event-Driven
-
Can someone recommend technologies for testing automation for API application?
We use pact and since introducing it we have significantly increased velocity and reduced test cycles as it catches things very early. For system tests we hand write them using whatever test frameworks the team is used to.
-
Advanced TypeScript Patterns: API Contracts
There is also Pact https://pact.io/ for a language agnostic pact testing.
-
Framework for end to end testing of microservices
When you wish to focus on the contract ( which kind of field is required, ...), you shoud use contract testing frameworks. As you seem to leverage a microservices, a consumer driven contract testing approach with a framework like Pact.js is recommended.
io-ts
-
TDD
Qué rico. Si tenés chance meté un proceso de code review fuerte, y para el tema de I/O probá a usar https://github.com/Effect-TS/schema ó https://github.com/gcanti/io-ts que les da una solución obvia al tema de "tipos para lo que devuelva el backend", aunque es en realidad mucho más capaz que eso.
-
Domain modelling with State Machines and TypeScript by Carlton Upperdine
My fave is still io-ts (https://github.com/gcanti/io-ts/blob/master/docs/index.md) as I find it more flexible than zod at the ingress. The author is also working on the Effect ecosystem which also looks interesting.
-
Why I Like Using Maps (and WeakMaps) for Handling DOM Nodes
I’ve been using io-ts for this and been very happy with it. [1] It’s similar to Swift’s Coding protocol in case you’re familiar.
[1] https://gcanti.github.io/io-ts/
-
Can someone recommend a library for data parsing similar to Zod, but with better support for input transformations/preprocessing?
Yeah, there are a few new concepts and it's not the easiest to pick up right away. The best introduction is here on the main documentation page.
- libraries you are happy that you discovered them
- Is React for small projects an Overkill?
-
how to strictly type this?
We use https://github.com/gcanti/io-ts/blob/master/Decoder.md which has a very similar interface. It can even be used to mutate the data using https://github.com/gcanti/io-ts/blob/master/Decoder.md#the-parse-combinator.
-
Typescript advanced bits: function overloading, never and unknown types
A good way to significantly improve the reliability of your app is via improving type-safety by moving away from using any to unknown. One relevant example could be when you type your backend responses and when stringifying JSON to using unknown combined with some sort of runtime type checking. It can be done either by using built-in functionality like type guards or using an external library like io-ts, zod or yup.
-
I found 10,000x faster TypeScript validator library
Usage of TypeBox is similar with io-ts and zod, but it is much powerful and faster than them. Also, TypeBox can generate JSON schema very easily. Therefore, if you're looking for a validator library for new project and not suffering from legacy codes, I think TypeBox would be much better choice than io-ts and zod. TypeBox can totally replace them.
-
Validate your data with Zod
This check can be done with different libraries like: io-ts, typebox, or zod. These libraries allow you to create objects that represent your typescript definitions. Then, these objects can be used at runtime to validate the received data, in addition, you can also convert this object to a Typescript definition to have all the benefits of using typescript. These objects can be called schema validations because they are responsible for the data validation.
What are some alternatives?
Nock - HTTP server mocking and expectations library for Node.js
zod - TypeScript-first schema validation with static type inference
Karate - Test Automation Made Simple
class-validator - Decorator-based property validation for classes.
rust-wildbow-scraper - Automatically scrapes wildbow's web serials and compiles them into ebooks
openapi-generator - OpenAPI Generator allows generation of API client libraries (SDK generation), server stubs, documentation and configuration automatically given an OpenAPI Spec (v2, v3)
fp-ts - Functional programming in TypeScript
Robot Framework - Generic automation framework for acceptance testing and RPA
runtypes - Runtime validation for static types
mockoon - Mockoon is the easiest and quickest way to run mock APIs locally. No remote deployment, no account required, open source.
joi - The most powerful data validation library for JS [Moved to: https://github.com/hapijs/joi]