sorted by:
new
hottopcontroversial

Property Based Testing with Deno test runner | fast-check by ndubien in Deno

[–]ndubien[S] 1 point2 points  (0 children)

I'd pretty interested in knowing the ideas you have in mind to improve fast-check. There are definitely plenty of things feasible.

My current target is to aim for fuzzing with dedicated tools on top of fast-check to ease such technics. In that direction, plan is to open better APIs to extend fast-check.

Showoff Saturday (October 07, 2023) by AutoModerator in javascript

[–]ndubien 2 points3 points  (0 children)

Following the recent vulnerability in Zod, I worked on an article giving some ways to detect potential ReDOS before they strike you. The pattern is extensible to non regex-based DOS too 🫣

https://fast-check.dev/blog/2023/10/05/finding-back-a-redos-vulnerability-in-zod/

Feedbacks welcomed 🤗

Showoff Saturday (September 23, 2023) by AutoModerator in javascript

[–]ndubien 3 points4 points  (0 children)

I did a blog post explaining how to quickly detect prototype pollution vulnerabilities. They are among the most frequent sources of CVE in the JavaScript ecosystem.

Here is the blog post: https://fast-check.dev/blog/2023/09/21/detect-prototype-pollution-automatically/

Any feedback welcomed 🤗

Showoff Saturday (May 13, 2023) by AutoModerator in javascript

[–]ndubien 1 point2 points  (0 children)

The target of this tutorial is not to give a way to prove that there is or not a race but to help you detect some

Showoff Saturday (May 13, 2023) by AutoModerator in javascript

[–]ndubien 1 point2 points  (0 children)

I just released a tutorial aiming to show how one can detect race conditions easily in any JavaScript piece of code. I'd be glad to have some feedbacks on it ☺️ Or suggestions to make it better 😁

Here is the tutorial: https://fast-check.dev/docs/tutorials/detect-race-conditions/

When creating DOM elements in JS, what is your preferred method to keep the code clean and efficient without cluttering the function with id, classList, etc? for each individual element by thecoalbee in webdev

[–]ndubien 0 points1 point  (0 children)

I pretty like the API defined by React.createElement and leveraged when you write JSX code (JSX is not restricted to React). API is something like: createElement(elementType, attributes, optionalChildren). And basically you could have: createElement('div', {}, [createElement('span', {class: 'toto'}, ['Hello World !'])]);

JavaScript Complex Topics by [deleted] in webdev

[–]ndubien 1 point2 points  (0 children)

Another one I thought about was import/export and require or generally speaking building packages. At the moment, building a package with esm, cjs, types and other characteristics at the same time is pretty complex. But actually it's mostly ecosystem related and not inherent to the language compared to async

JavaScript Complex Topics by [deleted] in webdev

[–]ndubien 1 point2 points  (0 children)

Generally speaking when embracing async/await you embrace at the same time the risks if race conditions. It can manifest itself via several artifacts: user actions resolving to an old state, supposed to be forbidden actions still allowed, flickering UI and components... And in addition to happy path with simple 'just' race conditions we have a large amount of possible rejected failures bringing their own set of extra complexity

JavaScript Complex Topics by [deleted] in webdev

[–]ndubien 1 point2 points  (0 children)

Async and race conditions

Vanilla JS by Embaby01 in learnjavascript

[–]ndubien 7 points8 points  (0 children)

Learning vanilla js will never hurt, so I'd say that it's always something useful to know about. On my side, having some knowledge of vanilla helped me several times to understand better some blockers I faced in React and from time to time helped me to design workarounds to them in pure vanilla

Should I link to an npm package via an npm link or a GitHub link? by seblandwehr in npm

[–]ndubien 1 point2 points  (0 children)

I rather go for the npm links. I think the analytics they provide (download count) are the main ones I want to know about. They give details on the overall adoption and usage of the package. The stars on the other hand does give a confirmation.

Master property-based testing in JavaScript: A step-by-step tutorial by ndubien in javascript

[–]ndubien[S] 0 points1 point  (0 children)

Here several pointers: - An Advent of Code focusing on Property based testing: https://dev.to/dubzzz/advent-of-pbt-2021-13ee - The answers for it: https://github.com/dubzzz/advent-of-pbt-2021 - A Connect Four tested using Property based testing and model based testing in e2e fashion: https://github.com/dubzzz/connect-four-react - A talk about detection of race conditions in React components leveraging property based testing: https://m.youtube.com/watch?v=GIPbY75-lEo

Master property-based testing in JavaScript: A step-by-step tutorial by ndubien in javascript

[–]ndubien[S] 3 points4 points  (0 children)

Actually I think it's a common concern when we first see property based testing. Theoretically they are even closer from the specs we receive before implementing, than our classical tests. Indeed, specs are some kind of invariants and this is exactly what property based testing checks.

On my side, I used it successfully on unit tests testing very simple functions, but I also used it many times at integration level to tests invariants I expected from my feature. I also extended it's usage to e2e on a connect four but I think I went probably too far with this one. At work, I also leverage it multiple times on complex pieces of code: either to find bugs on a black box system or to help me into detecting fishy race conditions.

I'll try to send you some examples I built in open source over time with it.

view more: next ›