nzyme

Find the right React Unit Test Tools Pick up the right Unit Test tool for React Component is confusing, as the result of from google, hundreds of combination of chai+jsdom, jest+mocha, mocha+enzyme etc, come up to my eyes. Hey, Google, Can you just tell me the BESTest one and don’t make me think? ‘react unit test’ Unit Test of React Component is a bit different, rather than verifying output of functions, Unit Test in React requires 4 extra testing purpose ( ): Ref Artem Testing basic component rendering Testing props Testing events Testing event handlers Two most popular options are and . After spending hours in try out those tools, I end up in the great Jest Enzyme Airbnb open sourced Enzyme. jest is a JavaScript test runner maintained by Facebook. Included performance, mocking, , code coverage, sandbox. Jest snapshot When using Jest to test a React or React Native application, you can write a snapshot test that will save the output of a rendered component to file and compare the component’s output to the snapshot on subsequent runs. This is useful in knowing when your component changes its behaviour. jsdom + Mocha provides React the required DOM to render to, implementing a suitable subset of browser’s DOM implementations entirely in node/io.js. jsdom Enzyme is a library that wraps packages like , and to create a simpler interface for writing unit tests (work with shallow rendering). React TestUtils JSDOM CheerIO Example This is the of the example using E to test React component: git nzyme Install $ git clone https://github.com/wahengchang/react-test-must-know$ npm install Run Tests $ npm test > jest**PASS ** src/__tests__/**simpleFoo-test.jsPASS ** src/__tests__/ Foo-test.js **Test Summary**› Ran all tests. (7 total in 2 test suites, run time 2.08s) › 7 tests passed Should know 1.Verfity values of state/proprs in a component const wrapper = shallow(<ComponentName />);

expect(wrapper.state().data).toBe('something');expect(wrapper.props().data).toBe('something'); 2.Verfity values of tag in a component const wrapper = shallow(<ComponentName />);

expect(wrapper.find('h4').length).toBe(1);expect(wrapper.find('h4').at(0).text()).toBe('Something'); 3.Simulating click event of a button const wrapper = shallow(<ComponentName />);

expect(wrapper.state().data).toBe('state1');wrapper.find('button').simulate('click');expect(wrapper.state().data).toBe('state2'); Trick Asserting style ( ) from wrapper.find('.myClassname') .get(0).style;   expect(containerStyle).to.have.property('opacity', '1'); Asserting class name ( ) from const span = mount(<Test />).find('span');expect(span.html().match(/style="([^"]*)"/i)[1]).toBe('color: #000;'); *Remark Shallow Rendering testing a component as a unit, import { shallow } from 'enzyme';const wrapper = shallow(<MyComponent />); Full Rendering Components that may with DOM APIs, or may require the full lifecycle in order to fully test the component (i.e., etc.) interact componentDidMount i mport { mount } from 'enzyme';      const wrapper = **mount**(<MyComponent />); Static Rendering It is used to render react components to and analyze the resulting HTML structure. static HTML import { render } from 'enzyme';const wrapper = render(<MyComponent />); enzyme.wraper A wrapper refers to the enzyme wrapper class that provides the API ( ). more wrapper. (Foo)wrapper. ('.icon-star')wrapper. ('button').simulate('click')wrapper. (<div className="unique" />)wrapper. ().datawrapper. ().data find find find contains props state Reference: https://github.com/wahengchang/react-test-must-know http://blog.iannelson.systems/12-reasons-why-i-love-unit-tests/ https://github.com/facebook/jest/blob/master/examples/snapshot/Link.react.js https://github.com/facebook/jest https://facebook.github.io/jest/docs/tutorial-react.html https://github.com/facebook/jest/tree/master/examples/snapshot https://www.codementor.io/vijayst/unit-testing-react-components-jest-or-enzyme-du1087lh8 https://hackernoon.com/testing-react-components-with-jest-and-enzyme-41d592c174f#.d3lo5wnl5 http://airbnb.io/enzyme/docs/api/shallow.html

[React] Review: Component Unit Test is easy

Hi All! Here is my weekly wrap-up. What’s in today’s newsletter? Dunning-Kruger Effect Idea: Self Compassion Question: Second & Third Order Consequences Quote: Podcast: David Greenberg - Ex-Chair NYMEX ($12 Billion Commodities Exchange) David Greene - Host of Bigger Pockets Podcast How To Unlock Your Inner Polymath (And Think Like Leonardo da Vinci) The Netflix Effect Article: Idea: Dunning-Kruger Effect Have you ever met someone so confident in their abilities, but so clueless in reality? Maybe they thought they were a great singer, but sounded like a dying cat. Or maybe they claimed to be an expert in something but made basic mistakes. That’s the Dunning-Kruger effect. Let me share a study and a story. A Study . A study was conducted by researchers from Cornell University and published in the Journal of Personality and Social Psychology They asked college students to take a 10-question test on American history and then estimate their own scores and the average scores of their peers. They also asked them to rate their own knowledge of American history compared to their classmates. The results showed that the students who scored the lowest on the test (bottom quartile) were the most likely to overestimate their performance. They estimated that they answered 5.8 questions correctly, when in fact they only got 2.6 right. They also thought that they scored better than 68.6% of their peers, when in fact they only did better than 12.5%. They also rated their own knowledge of American history as above average, when it was actually far below. A Story A bank robber named McArthur Wheeler was arrested in 1995 after robbing two banks in Pittsburgh. He was easily identified by the security cameras because he did not wear a mask or disguise. When he was caught, he was shocked and confused. He said that he had applied lemon juice to his face, thinking that it would make him invisible to the cameras. He had tested his theory by taking a Polaroid picture of himself and not seeing his face on the film. He did not realize that he had made a mistake with the camera settings, and that his idea was completely absurd. This is a classic example of the Dunning-Kruger effect in action. Wheeler was so confident in his own logic and reasoning, but so ignorant of the reality. He did not have the skills or knowledge to evaluate his own plan or to learn from the feedback of others. He overestimated his abilities and underestimated the risks. The History The Dunning-Kruger effect is not a sign of stupidity, but of human nature. We all have blind spots and biases that can affect our perception of ourselves and others. The key is to recognize them and to overcome them. David Dunning and Justin Kruger showed us this with an experiment. They asked people to rate their own skills in logic, grammar, and humor. Then they tested them on those skills. The results were shocking. The people who scored the lowest on the tests also overestimated their abilities the most. They thought they were above average, when they were actually below average. Why? Maybe ignorance, maybe arrogance. Why? Here’s a possible explanation, competence is like a mirror. We judge ourselves by what we see. But what we see is not always accurate. It’s distorted by our biases, emotions, and expectations. We think we know more than we do. It’s like looking at a warped reflection. But asking for feedback from others? That’s where you could get a reality check. See, we fool ourselves with false confidence and miss the opportunity to improve. Think about it like bragging about a skill when you should be practicing it. But you can overcome the Dunning-Kruger effect. Try this: Seek honest feedback. Ask for it from people you trust. Listen to it with an open mind. Test your knowledge on topics. Challenge yourself with quizzes, puzzles, and problems. Learn from your mistakes. Admit your limitations. Be humble about what you don’t know. Be curious about what you can learn. One question to guide you all. Ask yourself: How do I know this? Knowing about the Dunning-Kruger effect is just step one. Acting on it, that’s the leap. Here’s a framework to help. The Four Stages of Competence The four stages of competence is a powerful mental model to help you learn anything faster and better and reduce the chance of you falling victim to the Dunning-Kruger effect. Here’s how it works. 1. Unconscious Incompetence You don’t know what you don’t know. You are blissfully ignorant of your lack of skill. You think you are better than you are. This is where the Dunning-Kruger effect kicks in. You overestimate your abilities and underestimate the difficulty of the task. How to escape this stage? Seek feedback. Ask for honest opinions from experts and peers. Don’t be afraid of criticism. Test your knowledge. Take quizzes, exams, or challenges. See how you compare to others. Recognize your limitations. Admit that you have a lot to learn. Be humble and curious. 2. Conscious Incompetence You know what you don’t know. You are painfully aware of your lack of skill. You realize you need to improve. This is where the learning process begins. You start to acquire new knowledge and skills. How to advance in this stage? Set goals. Define what you want to achieve and how you will measure your progress. Seek guidance. Find mentors, coaches, or teachers who can help you learn faster and better. Apply your learning. Practice what you learn. Apply it to real-world situations. Learn by doing. 3. Conscious Competence You know what you know. You are confident in your skill. You can perform well with effort. This is where the mastery process begins. You start to polish and perfect your skills. How to excel in this stage? Practice. Repeat what you learned until it becomes second nature. Aim for deliberate practice. Automate. Make your skills subconscious and effortless. Reduce the cognitive load. Optimize. Find ways to improve your performance. Seek feedback and fine-tune your skills. 4. Unconscious Competence You don’t know what you know. You are fluent in your skill. You can perform well with ease. This is where the innovation process begins. You start to create and expand your skills. How to innovate in this stage? Challenge yourself. Seek new and difficult problems. Push yourself beyond your comfort zone. Explore new domains. Learn new skills or combine existing ones. Cross-pollinate your ideas. Share your expertise. Teach others what you know. Help them grow and learn from them. The Four Stages of Competence is a mental model that helps you learn anything faster and better. It helps you assess your current level of skill and guide you to the next level. It also helps you avoid the pitfalls of the Dunning-Kruger effect by being humble, curious, and open-minded. Remember, it’s not about how good you think you are. It’s about how good you can be. So, the next time you feel confident about something, question it. Are you seeing yourself clearly, or are you blinded by your ego? It’s not about how good you think you are. It’s about how good you can be. Focus on the growth, not the illusion. Question: Self Compassion Here’s a question on how you treat yourself when you face difficulties: How often do you practice self-compassion in your life? Self-compassion is the ability to be kind, understanding, and supportive of yourself when you experience pain, failure, or hardship. It’s the opposite of being harsh, critical, or judgmental of yourself. Self-compassion is not a sign of weakness, selfishness, or complacency. It’s a sign of strength, resilience, and growth. Research has shown that self-compassion can have many benefits: Reducing stress, anxiety, and depression Enhancing well-being, happiness, and optimism Increasing self-confidence, self-esteem, and self-acceptance Improving relationships, empathy, and compassion for others Promoting healthy behaviors, such as exercise, diet, and sleep Facilitating learning, creativity, and productivity Some interesting studies: A meta-analysis of 79 studies found that self-compassion was associated with lower psychological distress and higher psychological well-being. A study of over 2,000 adults found that self-compassion was positively correlated with self-esteem, self-acceptance, self-confidence, and self-worth, and negatively correlated with self-criticism, self-doubt, self-blame, and self-deprecation. A study of over 200 college students found that self-compassion was positively related to academic motivation, performance, and learning goals, and negatively related to academic procrastination, anxiety, and fear of failure. A study of over 300 health care workers found that self-compassion was positively associated with physical health and negatively associated with unhealthy behaviors. A study of over 100 romantic couples found that self-compassion was positively related to relationship satisfaction, trust, intimacy, and commitment, and negatively related to relationship conflict, insecurity, and resentment. However,  even with the data and the benefits clearly researched, many people struggle with self-compassion. They  think that they don’t deserve it, that they need to be perfect, or that they need to punish themselves for their mistakes. Some people might also worry that self-compassion will make them lazy, indulgent, or irresponsible. But these are all myths. Self-compassion is not about avoiding responsibility, lowering your standards, or ignoring your problems. It’s about acknowledging your reality, accepting your imperfections, and taking care of your needs. Self-compassion is not about giving up, giving in, or giving yourself a free pass. It’s about giving yourself a break, giving yourself a chance, and giving yourself some love. This week, try to practice self-compassion in your daily life. Ask yourself: How do I talk to myself when I face a challenge, make a mistake, or feel inadequate? Do I use words of kindness, encouragement, and support, or words of criticism, blame, and shame? How do I treat myself when I feel hurt, disappointed, or frustrated? Do I offer myself comfort, care, and understanding, or do I ignore, deny, or suppress my feelings? How do I cope with stress, pressure, or uncertainty? Do I use healthy strategies, such as relaxation, meditation, or hobbies, or do I use unhealthy strategies, such as avoidance, distraction, or substance abuse? If you notice that you lack self-compassion, don’t beat yourself up. Instead, use this as an opportunity to practice it. Here are some simple ways to cultivate self-compassion: Use positive affirmations, such as “I am doing my best”, “I am worthy of love”, or “I am enough”. Write a letter to yourself, as if you were writing to a friend, expressing empathy, validation, and encouragement. Practice mindfulness, which is the awareness of your present moment experience, without judgment or resistance. Do something that makes you happy, such as listening to music, reading a book, or spending time with a loved one. Seek support from others who can listen, understand, and empathize with you. Remember, self-compassion is not a luxury, it’s a necessity. You deserve to be treated with kindness, respect, and dignity, especially by yourself. Quote: Second & Third Order Consequences “Failing to consider second- and third-order consequences is the cause of a lot of painfully bad decisions, and it is especially deadly when the first inferior option confirms your own biases. Never seize on the first available option, no matter how good it seems, before you’ve asked questions and explored.” - Ray Dalio It’s about the ripple effects of your actions. Successful people don’t just think about the immediate outcomes of their choices. They think about the long-term implications and trade-offs. First-order thinking is easy and tempting. It’s what most people do. Second-order thinking is hard and rare. It’s what sets you apart. Consider Jeff Bezos. He didn’t just see the internet as a way to sell books. He saw it as a way to transform commerce and customer experience. He didn’t just focus on short-term profits. He invested in long-term growth and innovation. He didn’t just react to the market. He anticipated and shaped the future. Second-order thinking is the key to making better decisions. It helps you avoid unintended consequences and costly mistakes. It helps you find hidden opportunities and creative solutions. It helps you outsmart the competition and achieve your goals. How do you practice second-order thinking? Ask yourself: And then what? What will happen next? What are the side effects? What are the alternatives? How will this look in 10 years? Don’t settle for the obvious answer. Dig deeper. Challenge your assumptions. Seek feedback. Learn from others. When you wake up today, think: Are you just skimming the surface? Or are you diving into the depths? Because after all, The quality of your thinking determines the quality of your life. Podcast: 1. David Greenberg - Ex-Chair NYMEX ($12 Billion Commodities Exchange) | | YouTube Spotify Apple David Douglas Greenberg has over 30 years of experience in the financial industry, serving as an executive chair and board member of the New York Mercantile Exchange (NYMEX), the world’s largest physical commodities exchange. He was part of the team that led the exchange to be the first to reopen after the 9/11 attacks. He played a key role in growing the NYMEX from a valuation of $800 million to $12 billion. 2. David Greene - Host of Bigger Pockets Podcast | | YouTube Spotify Apple David Greene is a former police officer turned real estate investor, agent, and author. He is the co-host of the BiggerPockets Real Estate Podcast, one of the most popular and influential podcasts in the industry. He is also the author of four best-selling books published by BiggerPockets including his latest book, the Pillars of Wealth. David has been featured on CNN, Forbes, HGTV, and other media outlets as a leading expert on real estate investing, wealth building, and personal development. 3. How To Unlock Your Inner Polymath (And Think Like Leonardo da Vinci) | | YouTube Spotify Apple In this Lessons episode we explore how to think like Leonardo da Vinci, a polymath who mastered the art of blending disciplines to unlock unprecedented creativity and innovation. Article: The Netflix Effect I’ve been a big fan of Scott Galloway’s podcast podcast for a while, and I think he really did Netflix justice in the written analysis he put together below. He examines how Netflix continues to defy the odds and retain its Iron Throne in streaming. There are some great business / professional / entrepreneur lessons. Some of the highlights: How Netflix's international expansion and content strategy paid off during the writers' strike Why the streamer's continued investment in originals separates it from the competition How the platform is raising prices thanks to its new utility status The threats posed by TikTok and YouTube Read it here. Also published here. Lead image by . King Lip on Unsplash If you love this kind of content, please subscribe to my or newsletter, check out my and connect with me on / . weekly daily , Podcast YouTube Twitter

Breaking the Illusion of Competence:  The Dunning-Kruger Effect 

Converging crypto use-cases with capital flows and the commodity supercycle + the quest for the uniquely-enabled app IMPORTANT NOTICE: This document is intended for informational purposes only. The views expressed in this document are not, and should not be construed as, investment advice or recommendations. Recipients of this document should do their own due diligence, taking into account their specific financial circumstances, investment objectives and risk tolerance (which are not considered in this document) before investing. This document is not an offer, nor the solicitation of an offer, to buy or sell any of the assets mentioned herein. Adjectives are important — Killer vs Uniquely Enabled In the search for value in a bear market, the blockchain public is pressed to believe that finding a single sweeping dApp or use case will drive user adoption and, as a result, the value of the underlying protocol. Some have shortsighted hopes to recycle killer but old ideas (Facebook, Uber, etc.) on a newer infrastructure. Blockchain, however, is not about continuing the previous chapter to fit in a Web 2.0 narrative for tech investing convenience. Instead, we look at underlying value drivers to narrow in on where the capital flows have historically and will flow into— on the crypto side to see what has traction ( ) and in the broader economy like Wall Street to see where value has accrued ( , ). The art of hunting for value propositions is to find their catalysts: uniquely enabled use cases, and not “overnight and killer successes.” Jeff Bezos started a before converting that momentum into a modern day infrastructure. thematically technical arbitrage industrial & expenditure drivers Commodity Supercycle very smart online bookstore A carrot on a stick is not enough to convince conservative institutions to adopt: unproven technology negative media coverage regulatory uncertainty expensive infrastructure cost to overhaul current technology systems While protocols can argue day and night about increasing network speed in the far future, this red herring shouldn’t necessarily limit the Enabled use-cases will not only bring unique value onto the blockchain, but will also act as a testing ground for future use cases and familiarity with the DLT platform. invaluable and immediate use-cases that can be provided today. In our report below, we explore one such use case that may possibly supersede the aggregate hesitations given the desperate needs for regulatory arbitrage and access to liquidity in trade finance and commodity trading industries. We dive further into the segments of the industry to find which part is in most need of disruption. process Segmenting trade finance & commodity trading assets Trade finance has been the backbone to globalization and world trade since the dawn of man. Yet the process continues to remains monolithic (to be tokenized), bears onerous reporting (to put on the DLT) and is held back by regulation (trustlessness, disintermediation). Commodities and natural resources underlie all global trade and compose a significant share of emerging markets exports. Copyright AP images — NYMEX open outcry. Trading commodities from orange juice to base metals... many but not all assets can be traded so easily. Already efficient assets such as /base metals, processed oil/gas or USD also fall into a “killer” mentality. Yes, they are the largest and most spectacular, but are they assets in need a solution? How much value is actually enabled by DLT on these popular assets? Fully redeemable, Swiss-vault, extremely accessible to remain competitive. gold gold ETFs (like SPDR) are starting to charge below their own operating costs Instead, and like diamonds, lithium or wood pellets are much more primed for retail access, increased liquidity, price transparency (esp. emerging markets) and tokenization, as many of these assets are not even open for trade to the commodity trading firms themselves. on trade finance is an excellent illustration of blockchain/DLT’s potential in the trade finance and supply chain management space —by unlocking value rather than reducing generic process/cost reduction, back to our point about “uniquely-enabled” diction delineation. For example, if a ship is in process of 3-month long delivery between India to Switzerland, one could trade this dead capital with tokenization to reduce financing & insurance costs. Note that nearly all of the world’s international trade is done . Nevertheless, these process-based, private blockchain solutions have already proven some roadblocks with lackluster adoption rates (e.g. ) that is attributable moreso to rather than a . inaccessible illiquid commodities WEF and Bain & Company’s recent report illiquid overseas, making geographic arbitrage a top priority for commodity traders IBM + Maersk initiative struggles product-design issue target market issue At the end of the report, our team looks into an open-sourced, decentralized solution that not only foils to private blockchain solution as an open access platform, but one that represents a form of liberation from financing banks and their associated legal threads ( Illiquidity, insurance costs, legal protection in trade finance are not results of malicious actors, but from poor mechanized design. So what kind of design would not only improve the system, but allow the public to also reap benefits from this newfound, economic surplus? We dive into a case study through . ie. Basel III, FinfraG, Dodd-Frank, EMIR, REMIT). ABC Platform Case Study Instead of focusing the process-side of trade finance and commodity trading, ABC Platform looks into the tokenization-side of illiquid, inaccessible assets with an thoughtful economic-model through its commodity-based token minting platform. Diving further, Taureon stress-tests the ABC team’s Monte Carlo model against its own bottom-up analysis from management-provided estimates of pipeline partners. The company has already secured a number of brand-name, corporate clients and partnerships which they will announce in the following months. Taureon is excited to see what Mathias and his team will accomplish as they moves toward launching their first product along side industry collaborators (they have to be careful with who they partner with, you wouldn’t want to trade assets with ) blackbox, closed-sourced pricing! In addition to investing and researching the Web 3.0 stack, Taureon continues to explore uniquely-enabled use cases in the blockchain space — from gaming to finance to supply chain to anything. Our team is open to both centralized and decentralized applications with the overlay that they leverage the transformative power of global blockchains as a catalyst of a new economic paradigm. Find the 37-page report here. Note the public report redacted select slides and information per request. (Disclosure: ABC platform is a portfolio company of Taureon Capital.)

Decentralized trade finance and hard-to-trade assets

The Bitcoin ETF: breaking down the CBOE ETF proposal

Superset uses and React Testing Library ( ) to write unit and integration tests. In the past we used , but now that we're currently converting all of our class components to functional components, Enzyme cannot support our testing needs. Since RTL is better for testing functional components, we're converting all of our test files to RTL. This can be quite a learning curve - I've gone through a lot of the process so I'd like to share what I've learned so far. Jest RTL Enzyme First and foremost: We have a document that outlines all the code styles we adhere to in our tests. Please use this document as a reference when writing your tests. Testing Guidelines and Best Practices The main thing you want to keep in mind is the different approaches each testing library uses in testing: It tests things in the "back" of the code that the user never sees, such as the props of a component. Enzyme is code-focused testing. All of your tests will rely on things the user can see and do. RTL is user-focused testing. For example: If there were an Enzyme test that checks the props of a component, you would look for where those props show visually on the component and capture it with RTL. Except for certain things like API mocking, Superset uses fetch-mock for that. , if you'd like to learn more about how to mock API calls in RTL. You can also look for other already-existing instances of fetch-mock in the codebase to see how it's used in Superset. Here's a link to the docs The test environment in Superset is getting healthier and easier to work with by the day, and I hope this will inspire you to help contribute to the cause! To wrap this up, I would like to leave you with some good RTL/testing resources: In your tests, use these commands to help with debugging: screen.debug() This will show you the rendered component in the console when you run the test. You can pass in a captured element if you want to see just that element instead of the whole rendered component. screen.logTestingPlaygroundURL() This will give you a link in the console when you run your test. Click this link and it will open an instance of the testing playground displaying your rendered component (or a captured element passed into the function) in the browser. for an example of what that looks like, this is a really cool feature 😁 It would look like this in the code: Check out this link const button = screen.getByRole('button');
screen.debug(button);
screen.logTestingPlaygroundURL(button); I converted 11 files in , feel free to use it as a reference for conversions this pull request The RTL docs have a good guide for converting from Enzyme RTL cheatsheet Jest matchers jest-dom matchers Superset has a very handy for RTL with supercharged functionality for our specific needs. helper file Originally posted . here Lead image source.

Testing Apache Superset: Migrating from Enzyme to RTL for Improved Testing

is a popular testing library for React applications, but it has limitations. One of the main criticisms of Enzyme is that it encourages a testing style focused on implementation details rather than behaviour. This can lead to brittle tests that break easily when the implementation of a component changes. Another limitation of Enzyme is that it is tightly coupled to the . This makes it challenging to use with other libraries or frameworks and can make it harder to write tests that are truly isolated from the implementation of the component. Enzyme React library If your project is using React+Enzyme and you dream about upgrading React version to 18 (and enjoying cool features like server-side and concurrent rendering) then I have bad news for you — Enzyme is dead and there would be no official adapters released compatible with future versions of React (you can still find some unofficial libraries but it would not trust them). The of this article is not only to explain the approach you may take to shift your test code to a new library but also to propose an idea of how you can automate the monitoring of the migration progress. MISSION Time to migrate! Migrating from Enzyme to a different testing library can be a , especially if you’re working on a large codebase. However, by taking an incremental approach, you can make the process much more manageable. daunting task An incremental migration involves gradually transitioning your tests from Enzyme to the new library, rather than trying to make the switch all at once. This approach has several benefits: It allows you to test the new library in a smaller, more controlled environment before committing to a full-scale migration. It minimizes the risk of introducing regressions or breaking existing tests. It allows you to learn and become familiar with the new library as you go, rather than trying to absorb everything at once. Here’s an example of how you might approach an incremental migration from Enzyme to a new library like (RTL): React Testing Library Start by identifying the tests in your codebase that are using Enzyme. These are typically the tests that import Enzyme or Enzyme-specific methods (such as or ). shallow mount Begin by migrating a small subset of these tests to RTL. This might be a component or set of components that you’re already familiar with, or a section of the codebase that doesn’t have a lot of dependencies. As you migrate each test, pay attention to how the test is structured and how it interacts with the component being tested. Take note of any differences in how the new library handles things like querying for elements or simulating events. As you migrate more tests, you’ll start to get a better sense of how RTL differs from Enzyme. Take advantage of this learning opportunity to refactor your tests and improve their overall structure and readability. Repeat steps 2–4 until all of your tests are using the new library. Finally, After you’ve completed your migration, make sure to run your test suite to make sure everything is working as expected. Overall, an incremental migration is a great way to move away from Enzyme and transition to a new testing library. By taking a step-by-step approach, you can minimize the risk of breaking things, learn the new library as you go, and make the overall migration process much more manageable. However, it is hard to know whether this approach is successful or not without knowing the metrics that describe the success. As tech lead of the team, how can you know that team follows the strategy you came up with and how far is the end ( )? step #6 TLDR; Link to the code GitHub repo: https://github.com/sr-shifu/eslint-plugin-enzyme-deprecation Write a plugin to track the progress! What tool do you usually use to enforce the coding style and find potential errors in your project? You probably got it right  — ! (If you answered TSLint, you’re a little behind the times!). ESLint is highly customizable, you can set your own rules, use your own formatter or combine both inside one plugin! It is also can be easily integrated into a development workflow, such as a continuous integration pipeline, to automatically report any issues before they committed. ESLint Writing a custom ESLint plugin is not as hard as you may think but you might need to spend more time learning deeper about Abstract Syntax Tree (tree representation of the abstract syntactic structure of source code written in a programming language) and ESLint to traverse this tree. Without further ado, let me introduce my solution: selectors const noShallowRule = require("./rules/no-shallow");
const noMountRule = require("./rules/no-mount");

const rules = {
  "no-shallow": noShallowRule,
  "no-mount": noMountRule,
};
module.exports = {
  rules,
  configs: {
    recommended: {
      rules,
    },
  },
}; THE END! . . . . Just kidding! Now, will come the most interesting part! Rules are rules Let’s go deeper into the rule’s code. Both and rules use the same logic (the idea to break them apart is simply for giving users more flexibility on what they want to deprecate), so let's dive deep into one of those (I picked ): no-shallow no-mount shallow const schema = require("./schema");
const astUtils = require("ast-utils");

const resolveEnzymeIdentifierInScope = (scope, name) => {
  if (!scope) {
    return false;
  }
  const node = scope.set.get(name);
  if (node != null) {
    const nodeDef = node.defs[0];
    if (
      nodeDef.type === "ImportBinding" &&
      nodeDef.parent.source.value === "enzyme"
    ) {
      return true;
    }

    if (
      astUtils.isStaticRequire(nodeDef.node.init) &&
      astUtils.getRequireSource(nodeDef.node.init) === "enzyme"
    ) {
      return true;
    }
  }

  return false;
};

module.exports = {
  meta: {
    messages: {
      noShallowCall: "Enzyme is deprecated: do not use shallow API.",
    },
    docs: {
      description: "Disallow Enzyme shallow rendering",
      category: "Tests",
      recommended: true,
    },
    schema,
    fixable: null,
  },

  create(context) {
    const [options = {}] = context.options || [];
    return {
      "CallExpression"(node) {
        if (
          node.callee.name !== "shallow" &&
          node.callee.property?.name !== "shallow"
        ) {
          return;
        }
        let targetDeclarationName = "shallow";
        if (node.callee.property?.name === "shallow") {
          targetDeclarationName = node.callee.object.name;
        }
        const resolved = context
          .getScope()
          .references.find(
            ({ identifier }) => identifier.name === targetDeclarationName
          ).resolved;
        const isEnzyme = resolveEnzymeIdentifierInScope(
          resolved?.scope,
          targetDeclarationName
        );
        if (isEnzyme || options.implicitlyGlobal) {
          context.report({ node, messageId: "noShallowCall" });
        }
      },
    };
  },
}; is an Enzyme selector that tells Enzyme that we are interested only in function calls. These selectors are pretty similar to CSS ones, you can learn more about them . CallExpression here refers to the name of the called function (in our case, shallow), while checks whether this function was called as a property of a higher-order object (for instance, ). node.callee.name node.callee.property?.name const enzymeApi = require('enzyme'); enzymeApi.shallow(<Component /> gives a reference to the scope where the target function ( ) was called and has a reference to the object that owns this shallow method. Basically, what we need to check here is that shallow method belongs to the enzyme source - usually enzyme imported into the test module, or required if you are using CommonJS (if you are curious, about how you can write the library that produces build for both EcmaScript Modules and CommonJS targets, go to this ). context.getScope() shallow article is an option that can be provided by the consumer of the rule, for instance in config file. In this specific example, it allows users to tell the rule that they are not interested in the source that shallow comes from options.implicitlyGlobal .eslintrc.js (maybe, you have assigned it to the global scope somewhere in your test setup flow - bad idea IMHO). Report your progress For brave souls who made it to this part, thank you, and let’s continue! Now we have rules that we can use to prevent pushing deprecated APIs as part of new and changed code in your PRs (hopefully, you are using Jest’s API as part of your Git pre-commit flow). findRelatedTests But we still don’t know how things look from a bird-eye view — maybe the team is mostly working on new parts of the project, completely forgetting about some legacy systems . For this case, we need to write a custom formatter to output the statistics. (or bypassing pre-commit hook — yikes!) I don’t want to throw huge blocks of the code here — you may find it in my GitHub but I will try shortly to explain how it works. After running the rules and collecting errors for each test file, ESLint plugin passes this metadata to the formatter: repo { 
    filePath: string; 
    messages: Array<{ruleId: string;}> 
} In the formatter, we group this data by file path and by violated rule id (e.g., ), and pass this processed data to the visualizer that might output this data in different formats. Just a few ideas about what these formats can be: enzyme-deprecation/no-shallow ASCII printed charts in the terminal (for running in local/dev environment) Markdown-based file written to the filesystem and pushed to the Git repo (for reviewing progress after each individual PR) HTML page using beautiful chart libraries (like D3.js) written to folder (assuming you might already have some integrations with this folder in your code review tool) coverage Plain string message passed to some webhook URL (e.g. Slack notification to code review channel) How to use it in your project? Option 1: Define separate ESLint config for migration : .eslintrc.migration.js module.exports = {
  parser: '<your-parser>',
  extends: ['plugin:enzyme-deprecation/recommended'],
  env: {
    browser: true,
  },
  rules: {
    'enzyme-deprecation/no-shallow': 2
  }
}; And in your file define command: package.json "track:migration": "NODE_ENV=development eslint --no-eslintrc --config .eslintrc.migration.js -f node_modules/eslint-plugin-enzyme-deprecation/lib/formatter --ext .test.jsx src/" Option 2: Using Node.js API You can find an example command in the root directory) here (run npm run demo Final words In summary, an incremental migration approach, combined with , can help you to migrate your codebase to a new testing library in a controlled and efficient manner. This will help you to write more consistent, error-free code and catch issues early in the development process. automation of monitoring Originally at published https://thesametech.com on January 16, 2023. You can also follow me on Twitter and connect on LinkedIn to get notifications about new posts!

Enzyme Is Dead — Here's How You Can Migrate

The Genetic Effects of Radiation by Isaac Asimov is part of HackerNoon’s Book Blog Post Series. The table of Links for this book can be found here . The Machinery of Inheritance: Enzymes and Genes Enzymes and Genes Each cell is a tiny chemical factory in which several thousand different kinds of chemical changes are constantly taking place among the numerous sorts of molecules that move about in its fluid or that are pinned to its solid structures. These chemical changes are guided and controlled by the existence of as many thousands of different enzymes within the cell. Enzymes possess large molecules built up of some 20 different, but chemically related, units called amino acids. A particular enzyme molecule may contain a single amino acid of one type, five of another, several dozen of still another and so on. All the units are strung together in some specific pattern in one long chain, or in a small number of closely connected chains. Every different pattern of amino acids forms a molecule with its own set of properties, and there are an enormous number of patterns possible. In an enzyme molecule made up of 500 amino acids, the number of possible patterns can be expressed by a 1 followed by 1100 zeroes (10¹¹⁰⁰). Every cell has the capacity of choosing among this unimaginable number of possible patterns and selecting those characteristic of itself. It therefore ends with a complement of specific enzymes that guide its own chemical changes and, consequently, its properties and its behavior. The “instructions” that enable a fertilized ovum to develop in the proper manner are essentially “instructions” for choosing a particular set of enzyme patterns out of all those possible. The differences in the enzyme-guided behavior of the cells making up different species show themselves in differences in body structure. We cannot completely follow the long and intricate chain of cause-and-effect that leads from one set of enzymes to the long neck of a giraffe and from another set of enzymes to the large brain of a man, but we are sure that the chain is there. Even within a species, different individuals will have slight distinctions among their sets of enzymes and this accounts for the fact that no two human beings are exactly alike (leaving identical twins out of consideration). Each chromosome can be considered as being composed of small sections called genes, usually pictured as being strung along the length of the chromosome. Each gene is considered to be responsible for the formation of a chain of amino acids in a fixed pattern. The formation is guided by the details of the gene’s own structure (which are the “instructions” earlier referred to). This gene structure, which can be translated into an enzyme’s structure, is now called the genetic code. Stained section of one cell from salivary gland of Drosophila, or fruit flies, reveals dark bands that may be genes controlling specific traits. If a particular enzyme (or group of enzymes) is, for any reason, formed imperfectly or not at all, this may show up as some visible abnormality of the body—an inability to see color, for instance, or the possession of two joints in each finger rather than three. It is much easier to observe physical differences than some delicate change in the enzyme pattern of the cells. Genes are therefore usually referred to by the body change they bring about, and one can, for instance, speak of a “gene for color blindness”. A gene may exist in two or more varieties, each producing a slightly different enzyme, a situation that is reflected, in turn, in slight changes in body characteristics. Thus, there are genes governing eye color, one of which is sufficiently important to be considered a “gene for blue eyes” and another a “gene for brown eyes”. One or the other, but not both, will be found in a specific place on a specific chromosome. The two chromosomes of a particular pair govern identical sets of characteristics. Both, for instance, will have a place for genes governing eye color. If we consider only the most important of the varieties involved, those on each chromosome of the pair may be identical; both may be for blue eyes or both may be for brown eyes. In that case, the individual is homozygous for that characteristic and may be referred to as a homozygote. The chromosomes of the pair may carry different varieties: A gene for blue eyes on one chromosome and one for brown eyes on the other. The individual is then heterozygous for that characteristic and may be referred to as a heterozygote. Naturally, particular individuals may be homozygous for some types of characteristics and heterozygous for others. When an individual is heterozygous for a particular characteristic, it frequently happens that he shows the effect associated with only one of the gene varieties. If he possesses both a gene for brown eyes and one for blue eyes, his eyes are just as brown as though he had carried two genes for brown eyes. The gene for brown eyes is dominant in this case while the gene for blue eyes is recessive. About HackerNoon Book Series: We bring you the most important technical, scientific, and insightful public domain books. ). THE GENETIC EFFECTS OF RADIATION This book is part of the public domain. Asimov, Isaac. (October 13, 2017 . Urbana, Illinois: Project Gutenberg. Retrieved June 2022, from https://www.gutenberg.org/files/55738/55738-h/55738-h.htm#c4 This eBook is for the use of anyone anywhere at no cost and with almost no restrictions whatsoever.  You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included with this eBook or online at www.gutenberg.org , located at https://www.gutenberg.org/policy/license.html .

Enzymes, Genes and Consistent Chemical Changes

Testing code is probably one of the most important things to do in software engineering. Testing ensures the quality of what we are building. There are many ways to test code, from end-to-end testing (manual testing) to unit testing (component testing in React). In this document, we’ll cover some of the most common and effective ways to test code using Jest, Enzyme, and other great . React tools Test Pyramid In Agile frameworks, automated testing can be grouped into a testing pyramid. A testing pyramid illustrates when we should use one testing method versus another. The pyramid shows that many unit-snapshot tests can be used to validate one integration test, and many integration tests can be used to validate one manual test. At the peak of the pyramid, we have an end-to-end test: manual testing of the whole application. The idea of choosing what type of tests should be used is important, as we may be testing the same thing in two or three different levels of the pyramid. Image 1. Test pyramid. Manual testing is slow and unsustainable. This type of testing works for our front-end applications because it mimics how the user will interact with our application. The problem with this testing is that it is expensive to maintain (any minor UI change may break the tests, because these tests are normally done with Selenium, a web browser emulator) and the time to develop one of this tests may be high. It’s important to note that we don’t usually use this type of testing in front-end applications due to high costs. Integration testing may be good to test connections between components and finding bugs in these For example, let’s imagine we want to test if a parent component passes specific props to a child whenever a user clicks a button. The cost of maintaining and doing these tests is not very high and will test parts that we don’t test with unit tests. liaisons. Unit/Snapshot testing is probably the easiest way to test components. We only focus on one isolated item and its logic. If we follow the presentation-functional components division, it will even be easier to test this. For presentational components, we give the props to the component and expect a specific render (could be a good use case for snapshot). In functional testing, the tests can be more tricky. We need to mock a redux store to create user actions, and we expect redux actions to be called by the mocked store while we simulate events. As rule of thumb for frontend development, start with unit/snapshot testing. Proceed to an integration test only if necessary. Try to avoid manual/UI testing. We can use Jest as our main testing tool for the first two steps of the pyramid. Why Jest? Make Testing Great Again with Jest. Jest is a testing framework created by Facebook. Facebook uses it to test JavaScript and React code. It was created under the premise of performance, features and adaptability. Jest provides an integrated “zero-configuration” experience. This is a differentiator from other popular testing frameworks like Mocha. Some of the killer features are: Immersive Watch mode only runs test files related to changed files. Instant Feedback: It runs parallel tests across workers, and buffers console messages and prints them together. Fast and sandboxed: Capture snapshots of React trees or other serializable values to simplify testing and analyze how state changes over time. Snapshot Testing: Supports for bringing out of the box coverage reports. Built-in code coverage reports: —-coverage Zero configuration Jest Matchers Matchers are the most basic unit for testing in Jest. They are used to assert that an expected object is equal, close to, greater, or less than, or contains any other logical connection to another output object. We can create different constructions with these logical connections. For more reference, check Jest . documentation test(‘object assignment’, () => {const data = {one: 1};data[‘two’] = 2;expect(data).toEqual({one: 1, two: 2});}); test(‘increasing a positive number is not zero’, () => {let a = 1;expect(a + 1).not.toBe(0);}); test('zero', () => {const z = 0;expect(z).not.toBeNull();expect(z).toBeDefined();expect(z).not.toBeUndefined();expect(z).not.toBeTruthy();expect(z).toBeFalsy();}); test('adding floating point numbers', () => {const value = 0.1 + 0.2;// It fails because in JavaScript 0.2 + 0.1 = 0.30000000000000004 jejeje.// expect(value).toBe(0.3);// This works with a precision of 5.expect(value).toBeCloseTo(0.3, 5);}); We can even test that an expected function throws an error: function compileAndroidCode() {throw new ConfigError(‘you are using the wrong JDK’);} test(‘compiling android goes as expected’, () => {expect(compileAndroidCode).toThrow();expect(compileAndroidCode).toThrow(ConfigError); // You can also use the exact error message or a regexpexpect(compileAndroidCode).toThrow(‘you are using the wrong JDK’);expect(compileAndroidCode).toThrow(/JDK/);}); Jest Mocks Mocking is a useful way to isolate components and functions. To do this, we define the output of our function/dependency. A good mock is the one that mimics all corner cases. Another excellent Jest feature is the ease of creating mocking functions/dependencies. If you aren’t mocking, you aren’t unit testing. test('computeList calls callback in array', () => {function computeList(items, callback) {for (let index = 0; index < items.length; index++) {callback(items[index])}} const mockCallback = jest.fn()  
                      .mockReturnValue(32)

computeList(\[0, 1\], mockCallback)

// The mock function is called twice  
expect(mockCallback.mock.calls.length).toBe(2)

// The first argument of the first call to the function was 0  
expect(mockCallback.mock.calls\[0\]\[0\]).toBe(0) }) Setup and teardown A good practice in Jest is organizing data in blocks. To do this, we can use function that receives two arguments: first the block name and then a function that will either have more organized blocks or test functions. To make it more modular, Jest provides a set of functions that will control code execution before and after we runtests. describe describe('City Database', () => {beforeAll(() => {initEnvironment()}) beforeEach(() => {  
    initCityDB()  
})  
  
afterEach(() => {  
    clearCityDB()  
})  
  
test('has Vienna', () => {  
    expect(isCity('Vienna').toBeTruthy())  
})  
  
test('has San Juan', () => {  
    expect(isCity('San Juan').toBeTruthy())  
}) }) Snapshot testing As projects evolve and change, code and tests need to evolve. The most complex part of writing unit tests for long-term projects is the maintenance. As project evolves, code evolves and naturally, tests evolve. Certain functions or components may change the output deliberately and tests may need to adapt their assertions. As illustrated in the image, this adaptation often has repetitive tasks. 2. Snapshot testing is a way to automate this process and create unit tests that can easily be overwritten and managed through time. The main benefit of snapshot testing is that we can quickly create tests for without much configuration, and adapt them to changes easily. black boxes Image 2. Unit Tests without Snapshots Imagine a function that filters a list of objects when given a keyword. One of the tests could be written as follows: test('function filters users', () => {expect(filterUsers('b').toEqual([{ name: 'Becky' },{ name: 'Bob' },{ name: 'Bryan' },{ name: 'Bryce' }]))}) But, what happens if we add users or change schema? We have to change the test, copying and pasting the assertion to make the test pass. The logic didn’t change, only the expected output. This can happen multiple times in a project. Snapshots are the solution to making this repetitive process automatic and auto-generated. test('filters items', () => {expect(filterUsers('b')).toMatchSnapshot()}) Jest has a built-in module that manages the creation and update of snapshots. It will save the snapshot in a directory titled Whenever we run Jest (if that directory exists), it will compare the output with the saved output. If it’s different we can easily overwrite the saved snapshot or check in the code for a possible bug. The following is an auto-generated snapshot: __snapshots__. // Jest Snapshot v1, https://goo.gl/fbAQLP exports[`Snapshots filters users 1`] = `Array [Object {"name": "Becky",},Object {"name": "Bob",},]`; Testing React Apps? Everything we’ve discussed so far doesn’t have a direct connection with React. All the previous tools may be used to test the logic of our front-end application. In frontend applications not everything is logic; we have a presentation that should be tested. But, how can we test this? The rule of thumb is that we should test everything that isn’t static. In other words, we should test two things: Given a set of inputs (state & props), assert what a component should output (render). Given a user action, assert how the component behaves. The component might make a state update or call a prop-function passed down from a parent. image 3. Tests for a simple form app. That is great, but if you think it twice, what would be the output of the presentational component that we’ll be testing or snapshotting? It would be the React Tree generated. Enzyme is the tool we’ll use to easily render without problems React Trees that could even be isolated (not rendering child components, for example). Enzyme Enzyme is a testing tool developed and managed by Airbnb. Enzyme uses several of the utilities provided by React to build its API. The API reduces boilerplate code. import App from '../App' describe('App component', () => {test('should shallow correctly', () => {expect(shallow(<App />)).toMatchSnapshot()})test('should mount correctly', () => {expect(mount(<App />)).toMatchSnapshot()})test('should render correctly', () => {expect(render(<App />)).toMatchSnapshot()})}) Enzyme has three methods for rendering React components. These methods give different results and we use them in different cases. We recommend always starting with Shallow. Use mount only when you need to test something related to the lifecycle. Render should be used when we want to test the children. Shallow rendering is useful to constrain yourself to testing a component as a unit, and to ensure that tests aren’t indirectly asserting the behavior of child components. Shallow: Full rendering and it doesn’t need an environment like a “browser”. This is useful when you want to test the children with less overhead than mount. Mount: Full DOM rendering is ideal for use cases where you have components that may interact with DOM APIs. Full rendering actually mounts the component in the DOM. This is the only way to test and . Render: componentDidMount componentDidUpdate We have API methods for the three methods that may help us in our assertions. Two of the most important are “simulate” and “find”. The first one can simulate user events like click, hover, etc. The second method can find a child with a selector. describe('the user populates the input', () => {const testem = 'Vancouver' beforeEach(() => {  
    const input = wrapper.find('input').first()  
    input.simulate('change', {  
      target: { value: testem }  
    })  
  }) test('should update the state property `testem`', () => {expect(wrapper.state().testem).toEqual(testem)})}) We are now ready to test our React application. Code with more concrete examples can be found . here

Using Jest and Enzyme for testing React Apps

This is the first of maybe a couple of posts that I am going to be doing on testing React components and TDD in general. This one deals with setting up the Jest and Enzyme libraries and then writing a couple basic tests for a Login component. In my next posts hopefully I’ll go into a little more detail about these libraries and about how we can test more complex components that involve Redux. So with that let’s get started! What is Jest? Jest is a testing library that can be used to test simple Javascript code or React components. This is done through simple API that Jest provides to users. Using this API it is possible to make assertions on how functions should behave and then test our expected outcome against the test outcome. It is very easy to set up and is usable right out of the box. Thats why its the preferred testing library for Facebook. A cool feature that Jest has is snapshots. This takes a snapshot of your component and how it renders and then will compare that whenever doing other tests to let you know if something unexpected is happening. I won’t go into too much detail on snapshots because I’ll cover those in another post. When using Jest with Enzyme it is possible to test components through a mock DOM. What is Enzyme? Enzyme is another library commonly used with either Jest or Mocha and Chai. With Enzyme we can create a mock DOM to test whether components are rendered correctly, and whether they behave correctly when acted upon. Enzyme’s mock rendering can either be done through shallow rendering or full DOM rendering. is used when doing unit testing of a component. This allows for tests to focus only on that component and how it functions, without caring about other components it might interact with. Shallow rendering involves rendering your component and all children components. The allows for more in-depth testing to see how your components on the DOM interact with each other. Full DOM rendering Setting up Jest and Enzyme First lets add both Jest and Enzyme to our React app. To install Jest simply run this code, npm install --save-dev jest Chance are it is already installed if you used Create React App to build the base of your application. Enzyme requires a couple of packages to be installed. First we’ll install Enzyme and the proper adapter to go with it. We must specify which version of React we are using to get the correct testing adapter. I am using React 15.6.1 so the packages I’ll be installing are npm install --save-dev enzyme enzyme-adapter-react-15 The full list of adapter packages can be found . Next we will install the Jest Enzyme package so we’ll be able to use them together like this, here npm install --save-dev jest-enzyme Now that we have both of the libraries installed we have to set up a couple more things. To begin lets set up our file structure. It is usually best to keep your component tests close to the component code. So lets create a subfolder called __tests__ in our components folder. This is where we will create a file for each component to write our tests. One last thing we need to set up is our adapter. In order to use Enzyme with React, we need to create another file and tell Enzyme what adapter to use depending on our version of React. This is where we will use that package we installed earlier, that corresponded to our React version. Because I used Create React App we can create a file called setupTests.js in the src folder. The code would look like this // in app/src/setupTests.js file const Enzyme = require('enzyme'); // this is where we reference the adapter package we installed// earlierconst EnzymeAdapter = require('enzyme-adapter-react-15'); // This sets up the adapter to be used by EnzymeEnzyme.configure({ adapter: new EnzymeAdapter() }); Time to Start Testing Now that we have everything set up we can begin writing our tests. The component we’ll test is a simple Login component. We will create our test file in our __tests__ folder that we made earlier. It should look like this, // path with the example test file nameapp/src/components/__tests__/Login-test.js If you are new to both of these libraries, like myself, I suggest looking at their documentation in order to determine the correct API methods to use for your tests. The first thing we have to do is import our component, React and a couple of functions from Enzyme. We’ll import shallow, mount, and render from Enzyme because these will mock our component rendering in the DOM. We will only use shallow for now, because we don’t need to test interaction between this component and others. // Login-test.js import React from 'react';import { shallow, mount, render } from 'enzyme';import Login from '../Login'; So normally in Test Driven Development (TDD) we write tests first, then write the function or component to make these tests pass. But since this is an example, I’ll give the sample code for the component to see how we select parts of the code to test. // app/src/components/Login.js import React from 'react'; class Login extends React.Component { constructor() {super()this.state = {username: '',password: ''}} handleInputChange = (event) => {this.setState({[event.target.name]: event.target.value})} render() {return (<form className='login'><label>Username</label><input id='email' onChange={this.handleInputChange} name='email' type='text' /><label>Password</label><input id='password' onChange={this.handleInputChange} name='password' type='password' /><button>Submit</button></form>)}} export default Login So first we write our describe functions to describe what we are testing, then we write our assertions about the behavior of certain parts of the component. This test checks to see if our component renders to the DOM properly, import React from 'react';import { shallow, mount, render } from 'enzyme';import Login from '../Login' // describe what we are testingdescribe('Login Component', () => { // make our assertion and what we expect to happenit('should render without throwing an error', () => {expect(shallow(<Login />).find('form.login').exists()).toBe(true)})}) This test is shallow rendering our Login component, then we check to see if our form node exists in the rendered HTML. Now that we know the form renders successfully, we can add a couple more simple tests to make sure that the inputs on our form render correctly too. // within the Login components describe function it('renders a email input', () => {expect(shallow(<Login />).find('#email').length).toEqual(1)}) it('renders a password input', () => {expect(shallow(<Login />).find('#password').length).toEqual(1)}) In both of these tests we are using the find function provided by Enzyme to find our inputs using their ids. Since find returns all the nodes that match our search terms we are just checking to make sure there is one of each input. We can simply check the length to see if the node exists. Now lets move on to simulating input changes. This is a controlled form so we can test when an input is changed, to see if it successfully changes the state of our Login component. To do this we’ll use the simulate function provided by Enzyme, and pass in as the second argument our simulated event object. The test will look like this, // within the Login components describe function describe('Email input', () => { it('should respond to change event and change the state of the Login Component', () => { const wrapper = shallow(<Login />);wrapper.find('#email').simulate('change', {target: {name: 'email', value: ' '}}); blah@gmail.com expect(wrapper.state('email')).toEqual(' ');})}) blah@gmail.com describe('Password input', () => { it('should respond to change event and change the state of the Login Component', () => { const wrapper = shallow(<Login />);wrapper.find('#password').simulate('change', {target: {name: 'password', value: 'cats'}}); expect(wrapper.state('password')).toEqual('cats');})}) So what happens when we call shallow on our Login component, is that instead of returning the rendered component, it returns a wrapped version of the component. That is why I set the value of wrapper to the shallowly rendered Login component. Next, we simulate a change event called on our inputs with our mocked event data. The way the simulate function works is it doesn’t actually simulate the event. It instead looks for the prop corresponding to that event on the selected node, in this case onChange, and calls it passing our mock event data. After we simulate the event we check the overall Login component’s state. We make sure that the onChange function was called properly and behaved properly, after the input was changed. With all these tests written like this, the output in your terminal should look like this, Summary These examples have just been some simple tests that you can write using Jest and Enzyme. The most important parts of these examples are the structure of them. Whenever writing tests, no matter what testing libraries are used, it is always important to structure them properly. This means organizing your tests logically under describe functions to focus on one part of the component at a time. Notice how I included a describe function for both my inputs, in order to make it clear that those tests focus on those specific parts of the component. This makes tests easier to understand and read for other programmers. Hopefully now you have an understanding of how to install these libraries, and how to start writing basic tests for your components! Check out the resources below for more documentation on what functions Jest and Enzyme allow you to use! Check out my next post to learn about Snapshot testing with Jest. For information on how to test Redux connected components check out my new post . Sources: _enzyme - JavaScript Testing utilities for React_github.com airbnb/enzyme _enzyme - JavaScript Testing utilities for React_github.com ShallowRenderingAPI 🃏 Delightful JavaScript Testingfacebook.github.io Jest · 🃏 Delightful JavaScript Testing

Implementing basic Component tests using Jest and Enzyme

A screenshot journey React Devtools — Inspiration Using Webpack’s “watch mode” is a great way to develop web apps. As you edit code, the app rebuilds and automatically reloads the page. Did you know Jest also has a watch mode? Snapshot-Driven Development jest --watch Watch mode lets you develop iteratively using snapshots of your components in different states as a way to confidently refactor and add features. In watch mode, Jest automatically re-runs your tests when files change. You can inspect changes and update snapshots with one keypress by pressing “u”. Cool! Let’s walk through a scenario: Adding tests to a simple app boostrapped with create-react-app. The App component The first test Adding a snapshot Refactoring the header into its own component: updated snapshot Adding props and condtional logic to the new Header component: snapshot fails Adding props and condtional logic to the new Header component: updated snapshot Shallow rendering To avoid coupling the Header implementation to the App component, we can use Enzyme’s shallow render and Enzyme-To-JSON to snapshot only the top level render tree. Switching to a shallow snapshot: snapshot fails Switching to a shallow snapshot: updated snapshot Moving beyond snapshots — .find() and Markers As you add more snapshot tests you may discover that some become brittle, need to be updated to often, or that you want to assert about more specific results than what high-level snapshotting provides. To make DOM tests more resilient you can use “test markers” (special classes or data tags that are only meaningful to tests). For example, the Header component can be rendered into different states but it might be nice to assert that something specific appears when logged in and something else when logged out. Add a test marker and use Enzyme DOM traversal methods like .find to assert that they appear when expected. Shallow rendering the Header in different states _Adding test marker tags (_ data-test="xyz") and .find() Zoomed in on the marker implementation At this stage we might consider removing the snapshots altogether since we’ve identified and expected what we care about. Testing Stateful Components Next up: Testing stateful components using Enzyme ( ) component.setState Mocking dependencies as an alternative to shallow rendering ( ) jest.mockFn() Test harnesses for React Context and other globals Discussions around the web — when to use snapshots https://tinyletter.com/kentcdodds/letters/effective-snapshot-testing https://www.briefs.fm/3-minutes-with-kent/49 https://www.bignerdranch.com/blog/integrated-testing-with-react-native-part-2-minimize-coupling/ https://twitter.com/thejameskyle/status/920014248654151680 https://twitter.com/searls/status/919594505938112512 Adding Jest & Enzyme yarn add --dev react-test-renderer jest enzyme enzyme-adapter-react-16 jest-enzyme enzyme-to-json Follow the instructions for your environment. Enzyme setup Demo App https://github.com/alexkrolick/snapshot-testing-demo

Stories, News & Mentions about NZYME

Nzyme’s Stories on HackerNoon