Well written set of tests plays a crucial role in delivering a reliable software. A good test suit ensures that the application works as intended and significantly reduces the number of bugs. It’s easier said than done. One of the steps to achieve this goal is adhering to boundaries of different test levels. In this article, I want to focus on the integration testing of decentralized applications that rely on web3. For integration testing, I’m able to sacrifice the speed of execution to gain the confidence that different components of the app seamlessly work together.
Decentralized applications present a new set of challenges. One of them is testing. Transaction lifecycle is more complex than the old-school POST request/response flow and errors are often less than helpful. Although developer experience is getting better, this puts into perspective how testing is essential.
Depends on how you count, second and third generation blockchain applications are not bound by restrictions of underlying protocols. Programmers can create smart contracts — distributed applications with access to code-controlled accounts. Use cases go far beyond exchanging value and applies where users benefit from replacing trust between parties with code.
Redux Thunk is one of the most if not the most popular Redux middleware with over 2 million downloads a month. If you compare this number to the Redux 4 million downloads a month, it is easy to figure out that over half of Redux projects are using Redux Thunk. As the name “thunk” suggests, the main goal of Redux Tunk is to allow for lazy evaluation (dispatching) of actions. While this makes it possible to dispatch actions in an asynchronous manner, it also makes it harder to test.
Fixtures are a thin abstraction layer over sample data in your application which allows for better organizing, often complex, data structures representing different entities. If this sounds like a vague description or does not ring the bell maybe an example will speak to you better.
Automated browser tests, in my case, are often part of continuous integration (CI). Failure = no deploy. This naturally creates some expectations towards acceptance/end to end testing framework. I haven’t found the tool which would meet all requirements although CodeceptJS is close. Nevertheless, no matter whether you use Protractor, Nightwatch.js, WebdriverIO, CodeceptJS or anything else based on Selenium you need to set it up and make it talk to the browser.