Have you ever needed market data for all the apps on Apple’s App Store? With over 2 million apps available for download market insights such as price, rating and how many ratings each app receives provides valuable insight to help you understand the market and plan your next app. The data set below, with a full set available soon, provides this information and is regularly updated.
Continue reading “Apple App Store Market Data for App Developers and Researchers”To Pin or Not To Pin the Version
Version pinning has become common practice and it usually seen as the way to go. This post highlights some of the benefits and issues with version pinning and highlights benefits of not pinning the version of dependencies only as required as a potential alternative.
Continue reading “To Pin or Not To Pin the Version”Don’t accidentally catch exceptions
It is commonly known that catching broad exceptions, such as Exception in a try...except block leads to issues around catching exceptions that should not have been caught and then are not handled correctly in the except block. A related issue is encapsulating too much code in a try...except block which can lead to catching exceptions on unexpected lines of code. This post provides an example where an except block unexpectedly catches an exception and gives an example for how to avoid the issue.
How to avoid pylint: disable=unused-argument in pytest
Have you seen or written something like the following in a test:
def test_something(some_fixture): # pylint: disable=unused-argument
...
Usually this is because a test depends on a fixture but doesn’t use the value provided by the fixture in the test. An example can be that the fixture makes a file available and the test just depends on the file being available without needing to know where the file is located or its content.
Continue reading “How to avoid pylint: disable=unused-argument in pytest”What should Python dictionaries be used for?
Whenever I use a package and get a dictionary returned from an API call I struggle to know what is in it, what the meanings of the values are and whether those values are always going to be there or only in specific circumstances. Whilst dictionaries have their place and are the only choice for certain use cases, they also have limitations and shouldn’t be used in certain cases. Below I’ll discuss a few example scenarios where dictionaries are useful and where they should be avoided.
Continue reading “What should Python dictionaries be used for?”Checking for specific messages in tests
There are a few cases where code contains human readable messages. Examples are log entries and exception messages. These kinds of messages typically are sentences like “there was a problem communicating with the server, please try again later.” It is usually important to check that log messages are written and exceptions are raised in tests. One of the approaches for these tests is to check that the exact message was written or raised. These kind of messages are subject to change to make them clearer to users which makes tests that check for the exact content of the messages prone to fail whenever the wording is adjusted. In this post we will explore some alternative approaches to writing these kind of tests that are less prone to false failures.
Continue reading “Checking for specific messages in tests”Should this code be in the test or a fixture?
There is some overlap between what could go into the setup phase of a test or into a fixture. There are a few reason why certain pieces of setup code are better suited to a fixture and also why other code might be better off in the test itself. This post explores a few examples to help illustrate how you can decide where to put the setup code to minimise the maintenance cost and maximise the value of the test suit.
Continue reading “Should this code be in the test or a fixture?”Is This Code Worth Testing?
Many of us face this question on a daily basis. In many cases, the answer is yes. In certain cases, the answer is no or somewhere in between. It is important to weigh the benefits against the cost, and consider the extent to which code should be tested. A code coverage tool may report a line of code as covered, but that does not guarantee it has been thoroughly tested. Another consideration is the kinds of tests we write to begin with. For example, should a private function have tests? Or should it be covered by the tests of a public function that makes use of it? Should a function be covered by integration tests or end to end tests? We will explore these questions by examining several examples of code and determine whether and which types of tests are worth writing.
Continue reading “Is This Code Worth Testing?”flake8-docstrings-complete Now Checks for Duplicate Descriptions
Version v1.1.0 of flake8-docstrings-complete has added new rules that ensure you only document each argument, raised exception and class attribute once:
DCO025: function/ method has one or more arguments described in the docstring multiple times.DCO056: function/ method has one or more exceptions described in the docstring multiple times.DCO065: class has one or more attributes described in the docstring multiple times.
Navigating Mocks in Python: Strategies for Safe and Efficient Mock Usage
Do you spend a lot of time on maintaining your mocks? Has your test suite passed and your code failed to run in production? This could be a result of using mocks too aggressively or not utilising safety features provided by Python’s mock library. In this post, we will explore the benefits and potential risks of using mocks, discuss strategies for designing high-level interfaces that are safe to mock, and examine a linter tool that ensures safe mock usage. Let’s begin by examining the potential risks associated with using mocks.
Continue reading “Navigating Mocks in Python: Strategies for Safe and Efficient Mock Usage”
David Andersson 