MUnit for Java Programmers: Test execution

Unit tests are executed at different stages during the development life cycle. As mentioned in the first blog post of this series, MUnit for Java Programmers: Introduction, unit tests play an essential role in the implementation, maintenance, and evolutionary stages of a project’s life cycle. Tests can be executed during each of these stages and the results are collected and analyzed. Should the application pass the series of tests it will continue on its journey through the project’s lifecycle.

MUnit for Java Programmers: Test doubles

What are test doubles?

A test double is a term used to describe replacing a dependent component of the functionality that is being tested with a dummy version of the real component — similar to a stunt double, only for unit tests. The test double only needs to emulate the behavior of the original dependent component closely enough that the functionality being tested doesn’t detect it’s not using the real component.

MUnit for Java Programmers: Test fixtures

February 26 2020

0 comments

Test fixtures, also known as a test context, sets up the conditions for a test to run. These test conditions will be a known good state that is specific to the code under test. When the test is completed, the state is restored or torn down. Conditions can be set up before a test suite executes and before a test runs. Test suites are extended further by parameterizing executions, enabling the same test to run different inputs. 

MUnit for Java Programmers: Test Assertions

February 20 2020

0 comments

At the heart of unit tests are assertions which provide a mechanism for comparing expected outcomes with actual outcomes. JUnit provides a large selection of overloaded convenience methods that perform predefined logical assertions, such as testing for equality, negations, and conditions specified by a matcher. MUnit also provides a similar set of assertion capabilities such as to assert two values as equals, validate a logical condition, and a variety of other custom assertions that replicate familiar JUnit assertions.

An introduction to MUnit for Java programmers

February 13 2020

0 comments

Unit tests are an integral part of the software development lifecycle. However, for most it is a task that must be endured and compounded by what seem like arbitrary test coverage targets.

In this blog, I will introduce MUnit by making reference to concepts already familiar to Java developers, thereby making the transition to MuleSoft developer and architect smoother.

Asynchronous Messaging Patterns

Asynchronous messaging enables applications to decouple from one another to improve performance, scalability, and reliability. This post will review the most common messaging patterns, along with why and when to use them. 

So, is a modern microservices architecture the ultimate answer to everything?

This is the third blog in a series explaining how MuleSoft’s Anypoint Platform can provide agile connectivity across monolith, SOA, and microservices architectures.

In my last blog, I reviewed the different types of architectures that have evolved over the last decade and how that has now led to the commonly used microservices architecture approach. This post will discuss whether this is the ultimate answer to architecture development,

The road to microservices: an overview of architectures

This is the second blog in a series explaining how MuleSoft’s Anypoint Platform can provide agile connectivity across monolith, SOA, and microservices architectures

In my last blog post, I discussed the impact agility has on business and IT, what it means for a business to be agile, and how implementing flexibility within your architecture enables business agility. This post will discuss the different architectures that have been prominent in previous years and how they’ve influenced the architecture of today. 

Introducing the Validations Module

This all began with a very popular request: “We want to be able to throw an Exception from a flow”. The motivation for this is that it’s fairly common to run into “business errors” (errors not related to the handling and transmission of data but the data itself) which should actually be treated in the same way as a connection or system error (things like the remote endpoint is down).

Given the popularity of the request we decided to look into it and started by asking: “which are the use cases in which you would throw an exception?”.

Synchronous and Asynchronous Throttling

motif

One of the most common use cases while building flows/applications in mule is to be able to communicate to external systems. The performance of that external system is often beyond the user’s control. It could be possible where the rate at which mule flow sends the messages outbound is faster than the rate at which that external system could process the message. In such scenarios, there is a need to be able to perform some kind of throttling so that we don’t burden/break the external system.