Vulnerabilities before change: Unintuitive scopes Bad readability of helper methods

Basic solution - introduce ActiveRecord::Enum, as simple as possible 5 various steps to improve enums functioning Ultimate solution - wrap all improvements into one implementation

There's no technical reason why you couldn't detect enum columns at startup time and automatically do this wireup, but I feel that the benefit of self-documenting outweighs the convenience.

the main reason we built a new multiprocess architecture is that Chromium's multiprocess support was never contributed to the WebKit project. It has always lived in the separate Chromium tree, making it pretty hard to use for non-Chrome purposes.Before we wrote a single line of what would become WebKit2 we directly asked Google folks if they would be willing to contribute their multiprocess support back to WebKit, so that we could build on it. They said no.

Privacy and security could be more widely compromised if there’s an issue with Chromium.

With Chromium taking so much market share, it’s easy to imagine competition slowing down and browser technology getting less diverse.

The formidable library of extensions is also a big draw: any browser based on Chromium can access all the third-party add-ons that help you customize your browsing according to your needs. If a development team wants to roll out an extension, it makes sense to prioritize Chrome. That’s where all the users are, and by basing your browser on Chrome, you get to ride along.

Threads are closed to new comments after two weeks, or if the submission has been killed by software, moderators, or user flags.

Can I ask people to upvote my submission? No. Users should vote for a story because they personally find it intellectually interesting, not because someone has content to promote.

Are paywalls ok? It's ok to post stories from sites with paywalls that have workarounds.

AdNauseam is a work in progress, with new features continually being added, tuned, and, sometimes, deprecated. If a setting no longer appears in the settings page, we have likely found a better means of implementing the design goal.

it might be due to the navigator.webdriver DOM property being true by default in Selenium-driven browsers. In Firefox, you can set the dom.webdriver.enabled config variable to false (go to about:config to change the variable), which disables this property. In my case this stopped reCAPTCHA triggering.

Length of your browsing sessions (Bots have predictable short browsing sessions)

Post some highly desirable content on line, and protect it with a copy of the captcha you need solved ... and record and re-use the solution your visitors give you

I'd slightly challenge: "By definition, resolving a CAPTCHA cannot be automated". The design goals are that it cannot be automated; however, not being automatable(?) does not follow by definition.

navigator.webdriver

The thing is that each UI decision depends on countless other UI decisions. A simple example is keybindings. On UNIX/Linux, it’s nearly impossible to pick reasonable default bindings for global desktop navigation because they all conflict with bindings that some app is using. On Windows, the desktop navigation bindings are hardcoded, and no app uses them, because apps know for sure which bindings to avoid.

do something specific and do it well

it’s extremely common to find a bug that only happens if some certain combination of options are enabled

Epiphany aims to present the simplest interface possible for a browser. Simple does not necessarily mean less-powerful. The commonly-used browsers of today are too big, buggy, and bloated. Epiphany is a small browser designed for the web: not for mail, newsgroups, file management, instant messaging, or coffeemaking. The UNIX philosophy is to design small tools that do one thing and do it well.

Flatpak is the best application distribution mechanism for Linux.

you probably referred to the positive case where no one overrides anything and so the property returns true, so no need to process further because it is really an automation. Yes, this is true. I just hope that it does not make websites skip the checks if this returns false.

many websites may try to prevent automated account creation, credential stuffing, etc by going beyond CAPTCHA and try to infer from different signals of the UA if it is controlled by automation.Processing all those signals on every request is often expensive, and if a co-operating UA is willing to inform a website that it controlled by automation, it is possible to reduce further processing.For instance, Selenium with Chrome is adding a specifically named property on document object under certain conditions, or phantomJS is adding a specifically named property on global object. Recompiling the framework/browser engine to change that identifier to circumvent the detection is always possible.WebDriver specification is just standardizing a mechanism to inform a website that co-operating user agent is controlled by automation. I don't think denial-of-service attack is the best example, so hopefully this change will clarify the goal. 

Determined "attackers" would simply remove the property, be it by re-compiling Chromium, or by injecting an early script (removing [Unforgeable] makes sure the latter is possible, I believe).Even non-determined ones could, when using the latter (it will simply be a built in part/option of the package for automated testing libraries).I think it provides no protection whatsoever and makes websites have some false sense of assurance.It is like using Content-Security-Policy and forget about any other client side protection - what about browsers that do not support it? What about browsers without that feature (manually disabled, using about:config, --disable-blink-features and the like, or customized builds)?I mean, it could be a nice property for other purposes (determining test mode and running some helper code that exposes a stable API for identifying key elements in the user interface, say, though I do not think that is a best practice), but certainly not for any abuse prevention.

When you need to proxy HTTPS traffic, the environment variable is upper case: HTTPS_PROXY

From the man pages The environment variables can be specified in lower case or upper case. The lower case version has precedence. http_proxy is an exception as it is only available in lower case. Using an environment variable to set the proxy has the same effect as using the --proxy option

REST and GraphQL are wonderful tools to create an API that is meant to be consumed by third parties. Facebook's API, for example, is consumed by ~200k third parties. It is no surprise that Facebook is using (and invented) GraphQL; a GraphQL API enables third parties to extensively access Facebook's social graph enabling them to build all kinds of applications. For an API with that many consumers, GraphQL is the fitting tool. But, to create an internal API (an API developed and consumed by code written by the same organization), RPC offers a simpler and more powerful alternative. Large companies, such as Netflix, Google and Facebook, are starting to replace REST/GraphQL with RPC for their internal APIs. Most notably with gRPC which is getting popular in the industry.

RPC is increasingly used to create backend APIs as most are internal: most of the time, a backend API is consumed only by frontends developed within the same organization. In general, REST and GraphQL are the right tools if you want to create an API consumed by code written by third parties and RPC is the right tool if you want to create an API consumed by code written by yourself / your organization.

The chosen approach pushes a lot of complexity out of the core. As a result it might take more code to achieve certain functionalities. This is the price of flexibility. And that's the primary design goal of Reactabular.

Reactabular has been designed to be extensible. Rather than implementing a lot of functionality in its core, it provides extension points. You can, for instance, customize rendering on cell level. It is possible to implement functionality, such as search, pagination, sorting, and inline editing, through composition.

Since games typically have perfect information, the outcome of the game is completely driven by the actions of the players.

how the Server-side Row Model can be configured with a Master / Detail view

how to nest grids inside grids using a Master / Detail configuration

This section introduces how React components using the ag-Grid Data Table can take advantage of a Redux store to simplify state management.

Grid API

Server-side operations with GraphQL

Total Footer Row

Why can't I keep using script whitelists in CSP? The traditional approach of whitelisting domains from which scripts can be loaded is based on the assumption that all responses coming from a trusted domain are safe, and can be executed as scripts. However, this assumption does not hold for modern applications; some common, benign patterns such exposing JSONP interfaces and hosting copies of the AngularJS library allow attackers to escape the confines of CSP.

However, a broader problem is that your script-src whitelist includes domains that host Javascript which can be used by an attacker who finds a markup injection bug in your application to bypass your CSP. For example, https://cdnjs.cloudflare.com hosts Angular (https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.7.2/angular.min.js) which can be used by an attacker to convert an HTML injection into arbitrary script execution (here is a paper about this).

What does composition have to do with mocking?Everything. The essence of all software development is the process of breaking a large problem down into smaller, independent pieces (decomposition) and composing the solutions together to form an application that solves the large problem (composition).

Put another way, mocking is required when our supposed atomic units of composition are not really atomic, and our decomposition strategy has failed to decompose the larger problem into smaller, independent problems.

peerDependencies

If you're writing a tool for developers, it's a really common case that you want to write a test to ensure that a good error or warning message is logged to the console for the developers using your tool. Before snapshot testing I would always write a silly regex that got the basic gist of what the message should say, but with snapshot testing it's so much easier.

These four things lead to a near total loss in the intended utility of integrated/functional tests: as the code changes make sure nothing is broken.

(After all, it's not like the past snapshot was well understood or carefully expressed authorial intent.) As a result, if a snapshot test fails because some intended behavior disappeared, then there's little stated intention describing it and we'd much rather regenerate the file than spend a lot of time agonizing over how to get the same test green again.

Because they're more integrated and try to serialize an incomplete system (e.g. one with some kind of side effects: from browser/library/runtime versions to environment to database/API changes), they will tend to have high false-negatives (failing test for which the production code is actually fine and the test just needs to be changed). False negatives quickly erode the team's trust in a test to actually find bugs and instead come to be seen as a chore on a checklist they need to satisfy before they can move on to the next thing.

They are generated files, and developers tend to be undisciplined about scrutinizing generated files before committing them, if not at first then definitely over time. Most developers, upon seeing a snapshot test fail, will sooner just nuke the snapshot and record a fresh passing one instead of agonizing over what broke it.

Good tests encode the developer's intention, they don't only lock in the test's behavior without editorialization of what's important and why. Snapshot tests lack (or at least, fail to encourage) expressing the author's intent as to what the code does (much less why)

I very rarely use snapshot testing with react and I certainly wouldn't use it with shallow. That's a recipe for implementation details. The whole snapshot is nothing but implementation details (it's full of component and prop names that change all the time on refactors). It'll fail any time you touch the component and the git diff for the snapshot will look almost identical to the one for your changes to the component.This will make people careless about to the snapshot updates because they change all the time. So it's basically worthless (almost worse than no tests because it makes you think you're covered when you're not and you won't write proper tests because they're in place).

I should also add that I'm in favor of relying more heavily on integration testing. When you do this, you need to unit test fewer of your simple components and wind up only having to unit test edge cases for components (which can mock all they want).

But isn't the point of testing to be confident the application works? Who cares if your unit works if the app is broken? I definitely want to know if the third party component I'm using breaks my use case. I mean, I'm not going to rewrite their entire test base, but if I can easily test my use case by not mocking out their component then why not do that and get the extra confidence?

it doesn't even render in-file components. For example, the <Fade /> component we have above is an implementation detail of the <HiddenMessage /> component, but because we're shallow rendering <Fade /> isn't rendered so changes to that component could break our application but not our test. That's a major issue in my mind and is evidence to me that we're testing implementation details.

The reason this kind of test fails those considerations is because it's testing irrelevant implementation details. The user doesn't care one bit what things are called. In fact, that test doesn't even verify that the message is hidden properly when the show state is false or shown when the show state is true. So not only does the test not do a great job keeping us safe from breakages, it's also flakey and doesn't actually test the reason the component exists in the first place.

I could rename toggle to handleButtonClick (and update the corresponding onClick reference). My test breaks despite this being a refactor.

I could mistakenly set onClick of the button to this.tgogle instead of this.toggle. My test continues to work, but my component is broken.

let's add a console.log(wrapper.debug()) which will log out the structure of what enzyme has rendered for us

Will this test break when there's a mistake that would break the component in production?Will this test continue to work when there's a fully backward compatible refactor of the component?

So finally I'm coming out with it and explaining why I never use shallow rendering and why I think nobody else should either. Here's my main assertion:With shallow rendering, I can refactor my component's implementation and my tests break. With shallow rendering, I can break my application and my tests say everything's still working.This is highly concerning to me because not only does it make testing frustrating, but it also lulls you into a false sense of security. The reason I write tests is to be confident that my application works and there are far better ways to do that than shallow rendering.

For instance, an integration test could verify that all necessary props are passed through from the tested component to a specific child component.

Often, if you are writing a test that amounts to “it does what it does”, or “it does exactly this, which happens to be duplicated in the application code”, then the test is either unnecessary or too broad.

Here are three rules of thumb I use to determine that something is not worth testing:Will the test have to duplicate exactly the application code? This will make it brittle.Will making assertions in the test duplicate any behavior that is already covered by (and the responsibility of) library code?From an outsider’s perspective, is this detail important, or is it only an internal concern? Can the effect of this internal detail be described using only the component’s public API?

Using with is not recommended, and is forbidden in ECMAScript 5 strict mode. The recommended alternative is to assign the object whose properties you want to access to a temporary variable.

pro & contra

To address many issues that have come up over the years, the API in v2 and above is not backwards compatible with the original React addon (v1-stable).

Yes, we've violated that "one assertion per test" rule, but that rule was originally created because testing frameworks did a poor job of giving you the contextual information you needed to determine what was causing your test failures.

No Match1 Match1+ MatchAwait?

Specifying a value for normalizer replaces the built-in normalization, but you can call getDefaultNormalizer to obtain a built-in normalizer, either to adjust that normalization or to call it from your own normalizer.

When you mock something, you're making a trade-off. You're trading confidence for something else. For me, that something else is usually practicality — meaning I wouldn't be able to test this thing at all, or it may be pretty difficult/messy, without mocking. (Like in our credit card example.)

May not fail when you break application code. False positives

Can break when you refactor application code. False negatives

This is called a false positive. It means that we didn't get a test failure, but we should have

This is what's called a false negative. It means that we got a test failure, but it was because of a broken test, not broken app code.

Why is testing implementation details bad?There are two distinct reasons that it's important to avoid testing implementation details. Tests which test implementation details:Can break when you refactor application code. False negativesMay not fail when you break application code. False positives

Discourse