Articles

Building on Ethereum (Part 3): Set Up and Test

,
In this series, I’m discussing the phases of a project encompassing a non-trivial set of Ethereum smart contracts and the React/Redux application that communicates with them.

The project, called In-App Pro Shop, aims to help Ethereum developers easily support in-app purchases, and it was written over the last half of 2018 as a way of learning about the Ethereum development ecosystem.

This project revealed many aspects of the power and constraints of Ethereum and its programming language Solidity. I hope to pass as much of that on to you as possible in this series.

Source de l’article sur DZONE

/0 Commentaires/par

Why Should You Be Invited to A Meeting?

,

There was a Twitter interaction about testers being invited or not to team meetings and about providing value to the team.

And it got me thinking.

Source de l’article sur DZone (Agile)

/0 Commentaires/par

Micronaut With Kotlin and Java With Groovy Tests

,

Recently, I came across Micronaut, a super light framework that fills the need for something in between Spring Boot and Vert.x.

I have been playing with it and wanted to see if I could get a simple project with Micronaut, a Kotlin/Java intermix for the (main) source code, and Groovy/Spock tests. Turns out it’s not that difficult. I just had to fiddle with it a little bit to get it right. So to save you time, here it is:

Source de l’article sur DZONE

/0 Commentaires/par

How to Expedite the Creation of JUnit Parameterized Tests

,

When writing unit tests, it is common to initialize method input parameters and expected results in the test method itself. In some cases, using a small set of inputs is enough; however, there are cases in which we need to use a large set of values to verify all of the functionality in our code. Parameterized tests are a good way to define and run multiple test cases, where the only difference between them is the data. They can validate code behavior for a variety of values, including border cases. Parameterizing tests can increase code coverage and provide confidence that the code is working as expected.

There are a number of good parameterization frameworks for Java. In this article, we will look at three different frameworks commonly used with JUnit tests, with a comparison between them and examples of how the tests are structured for each. Finally, we will explore how to simplify and expedite the creation of parameterized tests.

Source de l’article sur DZONE

/0 Commentaires/par

Problems Missed When Only Testing APIs Through UI

,

UI testing is an important part of quality assurance. Specifically, UI testing refers to the practice of testing front-end components to make sure that they do what they’re supposed to. If a user clicks the Login button, the login modal appears. If they click a link, they’re brought to the appropriate part of the application. With automation platforms, these individual tests can be linked together into workflows and automated. Business-driven development style tests can be created in this fashion. The UI can be tested to see that each individual path that a user may take is functional and that the interface is responding appropriately. Other platforms exist that allow these workflows to be tested on simulated resolutions and devices, ensuring that the user experience is consistent across all possible combinations of browser and device.

API testing lives a layer below UI testing. The UI is fed by these APIs and renders the DOM based upon conditions set by both the user and the developer. These conditions determine the sort of API call that’s made to populate the viewport. When we’re UI Testing, it could be argued that we are indirectly testing the API layer. It’s actually pretty fair to say so. Many of the actions that our UI platform will take will issue API calls. If the DOM rerenders correctly, we can assume to an extent that the API call was successful. The dangerous ground here is the assumption.

Source de l’article sur DZONE

/0 Commentaires/par

How to Build a Culture of Continuous Testing in Your Organization

,

The trends in software development are showing that more and more companies are adopting CI/CD methodologies to deliver their software applications. We all know that the market demands quicker releases. The days of waiting for months for new releases are gone. Software is now being released at record speeds! Adopting CI/CD does just that. It helps get your application out the door to the market as often as possible. However, one key aspect that seems to be overlooked is Continuous Testing. It’s great that CI/CD is getting software out quicker but quality should not be sacrificed. To solve that you have to test early, test often! Adding a culture of Continuous Testing to your model will provide the following benefits because now you’re focused on testing from the beginning of your SDLC

  • Faster Release Cycles
  • Better Code Quality
  • Better Test Coverage
  • Better Reliability

Now that we know to truly have a CI/CD methodology you need continuous testing as well. But just like adopting CI/CD, continuous testing requires an organizational culture shift. So how do you build that culture? It’s a different mindset that relies heavily on automation: Automated Unit Tests, Automated Functional and Non-Functional Tests, Automated Regression Tests, and Automated Deployments. Basically, anything that can be automated should be automated! That is the key principle of Continuous Testing, test from the beginning and automate as much as possible to ensure faster release cycles.

Source de l’article sur DZONE

/0 Commentaires/par