Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
How to start CI build faster by loading Ruby gems from cache on Github Actions? You can start running your tests for a Ruby on Rails project quicker if you manage to set up all dependencies in a short amount of time. Caching can be helpful with that. Ruby gems needed for your project can be cached by Github Actions and thanks to that they can be loaded much faster when you run a new CI build.
You will learn how to configure Github Actions using:
Thunderhead is the recognized global leader in the Customer Journey Orchestration and Analytics market. The ONE Engagement Hub helps global brands build customer engagement in the era of digital transformation.
Thunderhead provides its users with great insights into customer behavior. To continue to improve user experience with their highly-visual web application, Thunderhead develops continuously. How does Thunderhead keep this visual user experience working well? A key component is Applitools.
Most of us have faced beliefs that go unquestioned. Such ideas can vary from small daily matters such as grocery shopping to something as serious as religious matters. In my case, it was a professional belief, specifically whether or not integration tests are too slow.
There was a belief in our squad (and our chapter as well) that integration tests were slow and this belief made us not put this issue in our technical debts backlog and we all accepted it as a fact. It continued until the build time in some microservices exceeded 10 minutes and teammates started complaining about them. The first reaction was avoiding integration tests as much as possible and using unit tests instead. I know that it is not a wise decision against which there are many arguments, but It was the decision that the team made. In this post, we will see how this issue got resolved and the build time in our microservices decreased to half.
Everyone knows that 100% of code coverage does not exist and adds no added value. In fact, every day, what we really want is to test our business logic, the intelligence of our application.
In this article, we are going to start from a small Go-based CLI application that does not yet have unit tests, and then, we will do some gRPC unit tests.
In this post, we'll talk about the value of HTTP test doubles in the context of integration tests and introduce the WireMock module to use in Mule 4.
When writing integration software for distributed systems the most critical part to test is the interaction between those systems. Obviously, this makes integration tests vital. Traditionally, we would test against live systems, but having a local instance of an upstream system or a dedicated test instance can be expensive and/or difficult to coordinate its state between tests.
Instead, we can opt to verify the interactions against test doubles, also known as narrow integration tests. WireMock is a pretty popular HTTP server test double that allows us to configure stubbed responses for particular requests, as well as verifying that the requests it received match what we expect the system under test to have made.
Java::Geci is a code generator that runs during unit test time. If the generated code fits the actual version of the source code, then the test does not fail. If there is a need for any modification, then the tests modify the source code and fail. For example, there is a new field that needs a setter and getter. Then, the accessor generator will generate the new setter and getter and then it fails. If there is no new field, then the generated code is just the one that is already there — no reason to touch the source code: The test that started the generator finishes successfully.
Because Java::Geci generators run as tests, which is at run-time, and because they need access to the Java code structures for which they generate code, Java reflection is key for these generators.
WordPress 5.2, released last week, added two new pages to the WordPress backend to help users diagnose common configuration issues. The Site Health Check page runs a series of tests and categorizes the results as critical, recommended, and good. This helps users prioritize which issues require immediate attention.
WordPress 5.2 adds filters for developers to add, edit, or remove tests but these filters may not be as accessible as a plugin. Site Health Tool Manager by William Earnhardt is a new plugin that provides an easy way to disable tests.
In some situations, consultants may want to disable certain tests to prevent the results from panicking a client. For example, if a consultant has configured a site to not receive automatic updates because the site is managed with version control, the site health check test is unnecessary.
Disabling unnecessary tests can also increase a Site’s Health Percentage score. However, in the plugin’s description, Earnhardt stresses that the plugin should, “only be used to disable tests with a legitimate and acceptable reason for failing. It should not be used to hide tests which can be fixed.“
Site Health Manager also supports the tests that were recently added in Jetpack 7.3. Site Health Tool Manager is free and can be found on the WordPress plugin directory.