Amazon in brief blog post announced it will no longer include marijuana on its drug screening program. In short, the company is now treating weed like alcohol, which means off-work employees can partake in a beer or a spliff without fear of repercussions. Of course, just like with alcohol, Amazon says it will continue to do impairment checks and screen for drugs after on-the-job incidents.
The only exception mentioned involves positions regulated by the Department of Transportation — read: truck drivers and heavy equipment operators. Applicants for those jobs will still be screened for the marijuana.
This change comes as America is quickly warming to federal legalization of cannabis. Voters across the country, including conservative strongholds, are increasing passing measures granting citizens access to the plant. From medical to recreational use, America is waking up to legal pot and Amazon doesn’t want to be on the wrong side of history.
Amazon, in its statement written by Dave Clark, CEO of Worldwide Consumer at Amazon, acknowledges the changing political landscape, which is opening doors to legal weed and criminal expungement.
And because we know that this issue is bigger than Amazon, our public policy team will be actively supporting The Marijuana Opportunity Reinvestment and Expungement Act of 2021 (MORE Act)—federal legislation that would legalize marijuana at the federal level, expunge criminal records, and invest in impacted communities. We hope that other employers will join us, and that policymakers will act swiftly to pass this law.
Amazon confirmed its annual sales event known as Prime Day will be held on Monday, June 21 and Tuesday, June 22. Bloomberg had previously reported these same dates, citing leaked records. The once-a-year mega sale had typically been held in July, when the shopping season goes through its usual lull. But due to the COVID-19 pandemic, last year’s Prime Day was delayed until October in most markets, including the U.S.
Despite the changes, Amazon said small and midsize businesses generated mo0re than $3.5 billion during the Prime Day event, Amazon said, up 60% from the year prior. However, it didn’t disclose its total Prime Day figures.
This year, Amazon will kick off Prime Day early with a new promotion aimed at supporting small businesses. Starting June 7 and running up until Prime day’s start, when Prime members spend $10 on items sold by a participating small business, they’ll receive a $10 credit they can later spend during the Prime Day event.
This deal will run in select markets, including the U.S., U.K., France, Germany, Italy, Spain and Japan, and is the big promotion for small businesses in Amazon’s history, the company noted. More than 300,000 selling partners are participating.
Prime Day was originally conceived as a way to push more Amazon shoppers to convert to paying Amazon Prime subscribers by luring them with deep discounts across categories — including Amazon’s own consumer hardware devices, like Echo smart speakers or Fire TV devices, which have been regular best sellers.
This will again be the case, as Amazon promises savings and discounts across home, electronics, beauty, fashion and Amazon devices. And it will again extend sales to other areas of Amazon’s business, like Prime Video, Amazon Music, Prime Gaming and others.
One of those deals is live now, as Prime members are offered a four-month free trial for its on-demand music streaming service, Amazon Music Unlimited, which offers up to 70 million songs. The company recently added lossless streaming support as a free upgrade, following Apple’s move to do the same for its own Music subscribers.
While Prime Day has been running since 2015, Amazon has more recently begun using the event to put a stronger spotlight on how it helps small businesses in light of increased regulatory scrutiny and antitrust investigations over its business practices.
In addition to Congressional hearings which saw Amazon founder and (soon to be former) CEO Jeff Bezos hauled in to testify, DC’s Attorney General Karl Racine last month filed an antitrust suit against Amazon, accusing the retailer of stifling competition by exerting control over third-party sellers. The suit alleges Amazon fixed prices on its retail platform by prohibiting sellers from selling products for less elsewhere, creating an artificially high price floor across the online retail market.
The company is also facing antitrust investigations abroad, including in the E.U. The retailer has been accused of harming small businesses by leveraging nonpublic data from its third-party sellers who use its marketplace in order to copy the best-selling products and undercut its selling partners.
This reality stands in sharp contrast as to how Amazon presented itself during an upbeat press briefing, where it had leveraged actress Kristen Bell’s (“The Good Place”) likeability factor to promote how well small businesses were doing on Amazon. During the event, she “interviewed” favorite sellers, like dog food seller Pawstruck and artisanal self-care product maker Live by Being, who had nothing but great things to say about working with Amazon.
Bell, along with Karamo Brown and Mindy Kaling, will also be highlighting some of their favorite sellers on Amazon’s video shopping service, Amazon Live.
Amazon also gave a broader update on its small business sellers and related efforts. The retailer noted that, last year, it delivered more than 250 new tools and services to help its selling partners reach 300 million customers globally.
“It’s pretty incredible to think in the past year in the U.S. alone, our small and medium-sized selling partners sold more than 3.7 billion products as more than 7,200 products, every minute,” said Keri Cusick, head of Small Business Empowerment at Amazon, in a press briefing. “Overall, they average $200,000 in sales, up from about $150,000, and more than 27,000 American sellers had over half a million dollars in sales,” she added.
Amazon didn’t offer specifics about its upcoming Prime Day deals, but said that it will host hundreds of thousands of deals leading up to Prime Day from companies including Le Creuset, Tommy Hilfiger, Lego, Mattel and Black & Decker.
Alexa device owners can also shop early, starting on Friday June 18, by asking “Alexa, what are my deals?”
Prime Day will be available on Amazon.com or regional websites, on Amazon.com/espanol for Spanish-language speakers and in Amazon’s physical retail stores.
Pedro Duarte made a wishlist for styled code blocks in blog posts and documentation, then hand-rolls a perfect solution for that wishlist. For example, a feature to be able to highlight certain lines or words within the code block. The line highlighter is unique in that it only syntax highlights the highlighted lines, leaving the rest gray, which is a neat way to draw focus. And the word highlighter works via a RegEx. Pedro notes this isn’t a tutorial, it’s just a showcase of all the features that were stitched together using an existing combination of custom code and existing libraries. It’s pretty specific to React + Next.js + MDX, but apparently the core of it is based on rehype, which is new to me.
The results are pretty darn nice, modern-looking code blocks if you ask me! At the same time, I think it’s equally notable what’s not there as opposed to what is. I’ve seen (and tried) really featured-packed code blocks in the past, with features like a copy to clipboard button, a view raw code button, and export to whatever services. Pedro’s code blocks don’t even have an option to show the language in use.
Everybody’s wishlist is different. One thing that isn’t on Pedro’s wishlist is server-side rendering, but you can see on the blog post itself that it totally works with that (it’s presumably just Next.js at work). I’m pretty envious of that. Even though we’re ultimately both using Prism.js as the syntax highlighter, I’m only using it client-side. It occurs to me now that I could perhaps pull all this off in a Cloudflare Worker by using the HTMLRewriter — meaning it would essentially look like it’s done server-side and I could rip off the client-side copy of Prism. Maybe even more ideally, though, is that I’d do it as a WordPress plugin. Basically a PHP port of Prism, which seems like a tall order.
My wishlist for code block plugin…
Syntax highlighting (both on the rendered site and while authoring)
Server-side rendered <span class="token-foo"> stuff for syntax highlighting
Works nicely with the native WordPress block editor code blocks (```). For example, pasting in a code block auto-detects and uses the correct block. Easy to convert code to and from this kind of block.
Optional line highlighter
Optional line numbers
Optional word highlighter
Optional language display (and the ability to override that label)
Copy and paste very cleanly
No need to escape code while authoring
Freedom to style however on the front end (for modes, themes, custom scrollbars, etc). Styling code blocks has a million things to consider, so smart defaults should probably come with the plugin, but easy to override.
Stretch goal: can it somehow help with inline code as well?
The COVID-19 pandemic disrupted a lot in the world, and supply chains are no exception.
A number of applications that aim to solve workflow challenges across the supply chain exist. But getting real-time access to information from transportation providers has remained somewhat elusive for shippers and logistics companies alike.
Enter Project44. The 7-year-old Chicago-based company has built an API-based platform that it says acts as “the connective tissue” between transportation providers, third-party logistics companies, shippers and the systems. Using predictive analytics, the platform provides crucial real-time information such as estimated time of arrivals (ETAs).
“Supply chains have undergone an incredible amount of change – there has never been a greater need for agility, resiliency, and the ability to rapidly respond to changes across the supply chain,” saidJason Duboe, the company’s Chief Growth Officer.
And now, project44 announced it has raised $202 million in a Series E funding round led by Goldman Sachs Asset Management and Emergence Capital. Girteka and Lineage Logistics also participated in the financing, which gives project44 a post-money valuation of $1.2 billion. That doubles the company’s valuation at the time of its Insight Partners-led $100 million Series D in December.
The raise is quite possibly the largest investment in the supply chain visibility space to date.
Project44 is one of those refreshingly transparent private companies that gives insight into its financials. This month, the company says it crossed $50 million in annual recurring revenue (ARR), which is up 100% year over year. It has more than 600 customers including some of the world’s largest brands such asAmazon, Walmart, Nestle, Starbucks, Unilever, Lenovo and P&G. Customers hail from a variety of industries includingCPG, retail, e-commerce, manufacturing, pharma, and chemical.
Over the last year, the pandemic created a number of supply chain disruptions, underscoring the importance of technologies that help provide visibility into supply chain operations. Project44 said it worked hard to help customers to mitigate “relentless volatility, bottlenecks, and logistics breakdowns,” including during the Suez Canal incident where a cargo shipgot stuckfor days.
Looking ahead, Project44 plans to use its new capital in part to continue its global expansion. Project44 recently announced itsexpansion into Chinaand has plans to grow in the Asia-Pacific, Australia/New Zealand and Latin American markets, according to Duboe.
“We are also going to continue to invest heavily in our carrier products to enable more participation and engagement from the transportation community that desires a stronger digital experience to improve efficiency and experience for their customers,” he told TechCrunch. The company also aims to expand its artificial intelligence (AI) and data science capabilities and broaden sales and marketing reach globally.
Last week, project44 announced its acquisition of ClearMetal,a San Francisco-based supply chain planning software company that focuses on international freight visibility, predictive planning and overall customer experience. WIth the buy, Duboe said project44 will now have two contracts with Amazon: road and ocean.
“Project44 will power what they are chasing,” he added.
Will Chen, a managing director of Goldman Sachs Asset Management, believes that project44 is unique in its scope of network coverage across geographies and modes of transport.
“Most competitors predominantly focus on over-the-road visibility and primarily serve one region, whereas project44 is a truly global business that provides end-to-end visibility across their customers’ entire supply chain,” he said.
Goldman Sachs Asset Management, noted project44 CEO and founder Jett McCandless, will help the company grow not only by providing capital but through its network and resources.
Testing is one of those things that you either get super excited about or kinda close your eyes and walk away. Whichever camp you fall into, I’m here to tell you that front-end testing is for everyone. In fact, there are many types of tests and perhaps that is where some of the initial fear or confusion comes from.
I’m going to cover the most popular and widely used types of tests in this article. This might be nothing new to some of you, but it can at least serve as a refresher. Either way, my goal is that you’re able to walk away with a good idea of the different types of tests out there. Unit. Integration. Accessibility. Visual regression. These are the sorts of things we’ll look at together.
And not just that! We’ll also point out the libraries and frameworks that are used for each type of test, like Mocha. Jest, Puppeteer, and Cypress, among others. And don’t worry — I’ll avoid a bunch of technical jargon. That said, you should have some front-end development experience to understand the examples we’re going to cover.
Software testing is an investigation conducted to provide stakeholders with information about the quality of the software product or service under test.
At its most basic, testing is an automated tool that finds errors in your development as early as possible. That way, you’re able to fix those issues before they make it into production. Tests also serve as a reminder that you may have forgotten to check your own work in a certain area, say accessibility.
In short, front-end testing validates that what people see on the site and the features they use on it work as intended.
Front-end testing is for the client side of your application. For example, front-end tests can validate that pressing a “Delete” button properly removes an item from the screen. However, it won’t necessarily check if the item was actually removed from the database — that sort of thing would be covered during back-end testing.
That’s testing in a nutshell: we want to catch errors on the client side and fix them before code is deployed.
Different tests look at different parts of the project
Different types of tests cover different aspects of a project. Nevertheless, it is important to differentiate them and understand the role of each type. Confusing which tests do what makes for a messy, unreliable testing suit.
Ideally, you’d use several different types of tests to surface different types of possible issues. Some test types have a test coverage analytic that shows just how much of your code (as a percentage) is looked at by that particular test. That’s a great feature, and while I’ve seen developers aim for 100% coverage, I wouldn’t rely on that metric alone. The most important thing is to make sure all possible edge cases are covered and taken into account.
So, with that, let’s turn our attention to the different types of testing. Remember, it’s not so much that you’re expected to use each and every one of these. It’s about being able to differentiate the tests so that you know which ones to use in certain circumstances.
Unit testing
Level: Low
Scope: Tests the functions and methods of an application.
Unit testing is the most basic building block for testing. It looks at individual components and ensures they work as expected. This sort of testing is crucial for any front-end application because, with it, your components are tested against how they’re expected to behave, which leads to a much more reliable codebase and app. This is also where things like edge cases can be considered and covered.
Unit tests are particularly great for testing APIs. But rather than making calls to a live API, hardcoded (or “mocked”) data makes sure that your test runs are always consistent at all time.
Let’s take a super simple (and primitive) function as an example:
Again, this is a basic case, but you can see that it covers a small edge case where someone may have neglected to provide a first name to the application. If there’s a name, we’ll get “Hello ${name}!” where ${name} is what we expect the person to have provided.
“Um, why do we need to test for something small like that?” you might wonder. There are some very important reasons for this:
It forces you to think deeply about the possible outcomes of your function. More often than not, you really do discover edge cases which helps you cover them in your code.
Some part of your code can rely on this edge case, and if someone comes and deletes something important, the test will warn them that this code is important and cannot be removed.
Unit tests are often small and simple. Here’s an example:
describe("sayHello function", () => {
it("should return the proper greeting when a user doesn't pass a name", () => {
expect(sayHello()).toEqual("Hello human!")
})
it("should return the proper greeting with the name passed", () => {
expect(sayHello("Evgeny")).toEqual("Hello Evgeny!")
})
})
describe and it are just syntactic sugar. The most important lines with expect and toEqual. describe and it breaks the test into logical blocks that are printed to the terminal. The expect function accepts the input we want to validate, while toEqual accepts the desired output. There are a lot of different functions and methods you can use to test your application.
Let’s say we’re working with Jest, a library for writing units. In the example above, Jest will display the sayHello function as a title in the terminal. Everything inside an it function is considered as a single test and is reported in the terminal below the function title, making everything very easy to read.
The green checkmarks mean both of our tests have passed. Yay!
If unit tests check the behavior of a block, integration tests make sure that blocks work flawlessly together. That makes Integration testing super important because it opens up testing interactions between components. It’s very rare (if ever) that an application is composed of isolated pieces that function by themselves. That’s why we rely on integration tests.
We go back to the function we unit tested, but this time use it in a simple React application. Let’s say that clicking a button triggers a greeting to appear on the screen. That means a test involves not only the function but also the HTML DOM and a button’s functionality. We want to test how all these parts play together.
Here’s the code for a <Greeting /> component we’re testing:
We already know describe and it from our unit test. They break tests up into logical parts. We have the render function that displays a <Greeting /> component in the special emulated DOM so we can test interactions with the component without touching the real DOM — otherwise, it can be costly.
Next up, the test queries <p> and <button> elements via test IDs ( #greeting and #show-greeting-button, respectively). We use test IDs because it’s easier to get the components we want from the emulated DOM. There are other ways to query components, but this is how I do it most often.
It’s not until line 7 that the actual integration test begins! We first check that <p> tag is empty. Then we click the button by simulating a click event. And lastly, we check that the <p> tag contains “Hello human!” inside it. That’s it! All we’re testing is that an empty paragraph contains text after a button is clicked. Our component is covered.
We can, of course, add input where someone types their name and we use that input in the greeting function. However, I decided to make it a bit simpler. We’ll get to using inputs when we cover other types of tests.
Check out what we get in the terminal when running the integration test:
Perfect! The <Greeting /> component shows the correct greeting when clicking the button.
End-to-end (E2E) testing
Level: High
Scope: Tests user interactions in a real-life browser by providing it instructions for what to do and expected outcomes.
E2E tests are the highest level of testing in this list. E2E tests care only about how people see your application and how they interact with it. They don’t know anything about the code and the implementation.
E2E tests tell the browser what to do, what to click, and what to type. We can create all kinds of interactions that test different features and flows as the end user experiences them. It’s literally a robot that’s interacted to click through an application to make sure everything works.
E2E tests are similar to integration tests in a sort of way. However, E2E tests are executed in a real browser with a real DOM rather than something we mock up — we generally work with real data and a real API in these tests.
It is good to have full coverage with unit and integration tests. However, users can face unexpected behaviors when they run an application in the browser — E2E tests are the perfect solution for that.
Let’s look at an example using Cypress, an extremely popular testing library. We are going to use it specifically for an E2E test of our previous component, this time inside a browser with some extra features.
Again, we don’t need to see the code of the application. All we’re assuming is that we have some application and we want to test it as a user. We know what buttons to click and the IDs those buttons have. That’s all we really have to go off of.
describe('Greetings functionality', () => {
it('should navigate to greetings page and confirm it works', () => {
cy.visit('http://localhost:3000')
cy.get('#greeting-nav-button').click()
cy.get('#greetings-input').type('Evgeny', { delay: 400 })
cy.get('#greetings-show-button').click()
cy.get('#greeting-text').should('include.text', 'Hello Evgeny!')
})
})
This E2E test looks very similar to our previous integration test. The commands are extremely similar, the main difference being that these are executed in a real browser.
First, we use cy.visit to navigate to a specific URL where our application lies:
cy.visit('http://localhost:3000')
Second, we use cy.get to get the navigation button by its ID, then instruct the test to click it. That action will navigate to the page with the <Greetings/> component. In fact, I’ve added the component to my personal website and provided it with its own URL route.
cy.get('#greeting-nav-button').click()
Then, sequentially, we get text input, type “Evgeny,” click the #greetings-show-button button and, lastly, check that we got the desired greeting output.
It is pretty cool to watch how the test clicks buttons for you in a real live browser. I slowed down the test a bit so you can see what is going on. All of this usually happens very quickly.
Here is the terminal output:
Accessibility testing
Level: High
Scope: Tests the interface of your application against accessibility standards criteria.
Accessibility tests make sure people with disabilities can effectively access and use a website. These tests validate that you follow the standards for building a website with accessibility in mind.
For example, many unsighted people use screen readers. Screen readers scan your website and attempt to present it to users with disability in a format (usually spoken) those users can understand. As a developer, you want to make a screen reader’s job easy and accessibility testing will help you understand where to start.
There are a lot of different tools, some of them automated and some that run manually to validate accessibilit. For example, Chrome already has one tool built right into its DevTools. You may know it as Lighthouse.
Let’s use Lighthouse to validate the application we made in the E2E testing section. We open Lighthouse in Chrome DevTools, click the “Accessibility” test option, and “Generate” the report.
That’s literally all we have to do! Lighthouse does its thing, then generates a lovely report, complete with a score, a summary of audits that ran, and an outline of opportunities for improving the score.
But this is just one tool that measures accessibility from its particular lens. We have all kinds of accessibility tooling, and it’s worth having a plan for what to test and the tooling that’s available to hit those points.
Visual regression testing
Level: High
Scope: Tests the visual structure of application, including the visual differences produced by a change in the code.
Sometimes E2E tests are insufficient to verify that the last changes to your application didn’t break the visual appearance of anything in an interface. Have you pushed the code with some changes to production just to realize that it broke the layout of some other part of the application? Well, you are not alone. Most times than not, changes to a codebase break an app’s visual structure, or layout.
The solution is visual regression testing. The way it works is pretty straightforward. Visual test merely take a screenshot of pages or components and compare them with screenshots that were captured in previous successful tests. If these tests find any discrepancies between the screenshots, they’ll give us some sort of notification.
Let’s turn to a visual regression tool called Percy to see how visual regression test works. There are a lot of other ways to do visual regression tests, but I think Percy is simple to show in action. In fact, you can jump over to Paul Ryan’s deep dive on Percy right here on CSS-Tricks. But we’ll do something considerably simpler to illustrate the concept.
I intentionally broke the layout of our Greeting application by moving the button to the bottom of the input. Let’s try to catch this error with Percy.
Percy works well with Cypress, so we can follow their installation guide and run Percy regression tests along with our existing E2E tests.
describe('Greetings functionality', () => {
it('should navigate to greetings page and confirm everything is there', () => {
cy.visit('http://localhost:3000')
cy.get('#greeting-nav-button').click()
cy.get('#greetings-input').type('Evgeny', { delay: 400 })
cy.get('#greetings-show-button').click()
cy.get('#greeting-text').should('include.text', 'Hello Evgeny!')
// Percy test
cy.percySnapshot() // HIGHLIGHT
})
})
All we added at the end of our E2E test is a one-liner: cy.percySnapshot(). This will take a screenshot and send it to Percy to compare. That is it! After the tests have finished, we’ll receive a link to check our regressions. Here is what I got in the terminal:
Hey, look, we can see that the E2E tests have passed as well! That shows how E2E testing won’t always catch a visual error.
And here’s what we get from Percy:
Something clearly changed and it needs to be fixed.
Performance testing
Level: High
Scope: Tests the application for performance and stability.
Performance testing is great for checking the speed of your application. If performance is crucial for your business — and it likely is given the recent focus on Core Web Vitals and SEO — you’ll definitely want to know if the changes to your codebase have a negative impact on the speed of the application.
We can bake this into the rest of our testing flow, or we can run them manually. It’s totally up to you how to run these tests and how frequently to run them. Some devs create what’s called a “performance budget” and run a test that calculates the size of the app, and will prevent a deployment from happening if the size exceeds a certain threshold. Or, test manually every so often with Lighthouse, as it also measures performance metrics. Or combine the two and build Lighthouse into the testing suite.
Performance tests could measure anything related to performance. They can measure how fast an application loads, the size of its initial bundle, and can even the speed of a particular function. Performance testing is somewhat broad, vast landscape.
Here’s a quick test using Lighthouse. I think it’s a good one to show because of its focus on Core Web Vitals as well as how it easily accessible in Chrome’s DevTools without any installation or configuration.
And here is our result:
Not a great score, but at least we can see what’s up and we have some recommendations for how to make improvements.
Wrapping up
Here’s a breakdown of what we covered:
Type
Level
Scope
Tooling examples
Unit
Low
Tests the functions and methods of an application.
So, is testing for everyone? Yes, it is! Given all the available libraries, services, and tools we have to test different aspects of an application at different points, there’s at least something out there that allows us to measure and test code against standards and expectations — and some of them don’t even require code or configuration!
In my experience, many developers neglect testing and think that a simple click-through or post check will help any possible bugs from a change in the code. If you want to make sure your application works as expected, is inclusive to as many people as possible, runs efficiently, and is well-designed, then testing needs to be a core part of your workflow, whether it’s automated or manual.
Now that you know what types tests there are and how they work, how are you going to implement testing into your work?
Critical CSS is one of those things I see in my performance reports but always seem to ignore. I know what it means. It means to put only the CSS required to render things immediately visible in a <style> tag in the <head> so it comes across in the first network request, then load the rest asynchronously, which will help the page load faster.
You’ve probably also seen the nag in Lighthouse performance reports as well:
Lighthouse tells me the critical CSS is an opportunity and even gives me a some WordPress-specific tips.
I’m not a big-complex-build-process sort of person, and unfortunately a lot of tooling for critical CSS involves including it within an existing build process.
I caught wind of Jetpack Boost and it’s designed to (among other performance-y things) make critical CSS easy for WordPress sites. Having a (free!) plugin that takes care of that really appeals to me.
Activating the plugin adds a “Jetpack Boost” item to the WordPress admin menu, and that leads to a handy screen that runs sorta like Lighthouse, but in WordPress. And wouldn’t you know, there’s an option to generate critical CSS right there. All I had to do was toggle the feature on and Jetpack Boost starts working.
My score can only go up from here, right?!
It doesn’t take long for the process to run. I switched windows to check my email for a minute and it was already done by the time I switched back. And, hey, look what it did for me while I slacked off:
Not too shabby for clicking one button! But we’ve gotta compare apples to apples, right? Let’s go back into Lighthouse to see what it says.
Now if only I could bring that initial server response time down. 🧐
We can even view the source to see that the proof is indeed in the pudding:
Whoa, that’s more than I expected!
It’s seriously cool to see the Jetpack team so focused on performance, and to the extent that they’ve dedicated an entire plugin to it. Performance has always been part of Jetpack’s settings. But making it front-and-center like this really allows Jetpack to do more interesting things with performance, like grading and critical CSS, in ways that go beyond basic settings. I’d imagine we’ll see more of Jetpack’s performance settings making the move over to the new plugin at some point.
