# unit tests Unit testing is a software development technique that isolates small units of code, such as methods, and verifies that they behave as expected. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Same-Day Model Integration: ESMC + ESMFold2 in Sheaf v0.11 DevFeed: [Same-Day Model Integration: ESMC + ESMFold2 in Sheaf v0.11]() Original publisher: [Read original article]() Published: 2026-05-27T00:00:00Z Content type: article Language: en Sources: [Alex Korbonits]() Topics: [Large Language Model](), [structure](), [Pydantic](), [backends](), [unit tests](), [Serverless]() Tags: [backend](), [claude-code](), [code](), [language](), [model](), [pypi](), [release](), [serverless](), [structure](), [tests]() ### AI overview The article explains how Sheaf v0.11 integrated ESMC and ESMFold2 on the same day they were released. It attributes the rapid integration to existing typed serving contracts and infrastructure, while describing verification, testing, H100 smoke testing, release work, and documentation. ### Source excerpt Chan Zuckerberg Biohub released a new protein language model and structure predictor this morning. Sheaf v0.11 shipped with both, same day. The story is less about hustle and more about what a typed serving contract buys you when a new model lands. ## TestParameterInjector introduces an idiomatic Kotlin API DevFeed: [TestParameterInjector introduces an idiomatic Kotlin API]() Original publisher: [Read original article]() Author: Google Open Source (noreply@blogger.com) Published: 2026-05-25T18:30:00Z Content type: release Language: en Sources: [Google Open Source Blog]() Topics: [Kotlin](), [Testing](), [unit tests](), [test-coverage](), [Java](), [Open Source]() Tags: [java](), [junit4](), [junit5](), [kotlin](), [open-source](), [parameterized-tests](), [test-coverage](), [testing](), [testparameterinjector](), [unit-tests]() ### AI overview Google announces KotlinTestParameters, a Kotlin-only API for TestParameterInjector. It uses Kotlin default function arguments to make parameterized tests type-safe, concise, and compatible with refactoring tools, avoiding string-based YAML maps and verbose provider classes. ### Source excerpt by Jens Nyman, TestParameterInjector Team In March 2021, we announced the open source release of TestParameterInjector: a simple but powerful parameterized test runner for JUnit4. In September 2022, we followed up with JUnit5 support, bringing our framework to developers who had moved on to the Jupiter API. We're excited to announce our biggest update yet for our Kotlin users: KotlinTestParameters. The de facto standard for parameterized testing When we first introduced TestParameterInjector, we shared a graph showing its rapid adoption within Google. Over the past few years, that trajectory has continued to a point where TestParameterInjector is the de facto parameterized test framework. Usage of all other alternative frameworks continues to steadily decline, while TestParameterInjector's adoption keeps growing rapidly. It has fundamentally lowered the barrier to writing data-driven unit tests, empowering Googlers and open source developers alike to maximize test coverage with minimal boilerplate. We believe its ubiquity internally is a strong testament to its reliability and utility for the broader developer communities. The Kotlin challenge As Kotlin's popularity has surged, developers have naturally been writing more of their TestParameterInjector tests in Kotlin. However, specifying explicit test values in Kotlin historically meant falling back to Java-centric paradigms. If you wanted to provide specific values to a test, you typically had three options, none of which felt truly idiomatic in Kotlin: @TestParameter({"123", "456"}): This relies on string arrays, limiting you to a subset of types that the string parsing supports. @TestParameters: This allows for more complex sets of data, but relies on YAML strings (e.g.,"{age: 17, expectIsAdult: false}"). These strings however are not type-safe, and are completely ignored by IDE refactoring tools. Provider classes: For complex types that couldn't be easily represented in strings, you have to write Provider classe ## Discovering iOS Memory Leaks IV: Detecting via Unit Tests DevFeed: [Discovering iOS Memory Leaks IV: Detecting via Unit Tests]() Original publisher: [Read original article]() Author: Amanjeet Singh Gurtatta Published: 2026-01-07T01:46:06Z Content type: tutorial Language: en Sources: [Amanjeet Singh]() Topics: [iOS](), [Memory Leaks](), [unit tests](), [Xcode](), [macOS]() Tags: [ios](), [macos](), [memory](), [memory-leak](), [memory-leaks](), [tests](), [unit-tests](), [xcode]() ### AI overview This article explores detecting real iOS memory leaks with unit tests instead of UI tests. It describes running the macOS leaks tool against the Firefox process during unit-test teardown in the iOS simulator to shorten the feedback cycle and broaden coverage. ### Source excerpt Using unit tests and macOS leaks tool to catch real iOS memory leaks. ## Eight daily ways an Engineering Manager uses AI for coding, planning, incidents, documentation, queries, unit tests, and debugging DevFeed: [Eight daily ways an Engineering Manager uses AI for coding, planning, incidents, documentation, queries, unit tests, and debugging]() Original publisher: [Read original article]() Author: Caleb Mellas Published: 2025-07-17T11:30:48Z Content type: opinion Language: en Sources: [Level up software engineering]() Topics: [Artificial Intelligence](), [coding](), [debugging](), [Documentation](), [unit tests]() Tags: [ai](), [coding](), [debugging](), [docs](), [engineering-manager](), [tests](), [writing]() ### AI overview An Engineering Manager describes eight practical daily uses of AI across coding, planning, incident work, documentation, complex queries, unit-test writing, and debugging. ### Source excerpt No BS practical everyday ways I use Ai for coding, planning, incidents, docs, complex queries, writing unit tests, debugging, and more ## Data-Driven Debugging for Engineers DevFeed: [Data-Driven Debugging for Engineers]() Original publisher: [Read original article]() Published: 2025-06-03T00:00:00Z Content type: tutorial Language: en Sources: [Vasya Drobushkov]() Topics: [debugging](), [bug](), [Development](), [unit tests](), [Code](), [Users]() Tags: [bugs](), [debugging](), [root](), [test](), [unit-tests](), [user]() ### AI overview This developer article explains how engineers debug bugs reported by developers, QA, and users. It compares the role of unit tests and end-to-end tests, then describes the greater difficulty of diagnosing vague user-reported symptoms. ### Source excerpt As engineers, we deal with bugs every day. Finding the root cause and delivering the right fix is one of our most essential -- and satisfying -- skills. In this post, I want to walk through different types of issues we face and how we typically debug them. Most importantly, I'll share my favorite and most challenging method: data-driven debugging. Let's break it down by who reports the issue and how it's discovered. ## AIDE: An AI-Assisted, Documentation-Driven Development Workflow DevFeed: [AIDE: An AI-Assisted, Documentation-Driven Development Workflow]() Original publisher: [Read original article]() Author: Peter Lawrey (noreply@blogger.com) Published: 2024-12-31T08:24:00Z Content type: tutorial Language: en Sources: [Vanilla Java]() Topics: [AI-assisted coding](), [Documentation](), [Test-driven development](), [Prompt Engineering](), [Requirements](), [Code generation](), [unit tests](), [Development]() Tags: [ai](), [documentation](), [github](), [guide](), [opinion](), [performance](), [prompt-engineering](), [requirements](), [testing](), [tests](), [training](), [unit-tests]() ### AI overview The article introduces AIDE, a workflow that combines AI-assisted code generation, structured AsciiDoc prompts, documentation-driven development, and test-driven development. It presents documentation as a single source of truth linking requirements, implementation, and tests, while leaving domain-specific logic and refinement to human developers. ### Source excerpt If it's worth doing by hand, it's worth automating. Just because not everyone is (yet) a world-class developer; that doesn't mean we can't step closer to that expert-level space. In this post, I will introduce AIDE (Artifical Intelligence Development Environment), a powerful workflow that merges AI-driven code generation with a sharp focus on documentation-driven development. With AIDE, I tap into the best of artificial intelligence (AI) while respecting the real human insight needed for domain-specific logic. The result? An environment that streamlines repetitive coding, synchronises requirements, code, and tests, and elevates your engineering game. Here is a practical example of an AIDE on GitHub developed using it's own AIDE. Introducing AIDE: Merging AI and Documentation-Driven Development AIDE transforms development by combining: Prompt Engineering with AsciiDoc: Clear, structured prompts guide AI to produce accurate, context-aware outputs. Documentation-Driven Development: Documentation as the "single source of truth" ensures alignment across requirements, tests, and implementation. Test-Driven Development: Unit tests validate outputs, forming a feedback loop between documentation and implementation. At times, AIDE makes you feel more like a curator than a coder. Yet, this curation--refining AI-generated scaffolds and aligning them with domain-specific logic--delivers impressive results. Why AIDE Empowers Developers Confidence in Documentation Documentation is the backbone of AIDE's approach. With a cohesive workflow: Single Source of Truth: AsciiDoc becomes a live blueprint, ensuring code, tests, and documentation stay aligned. Real-Time Updates: Incremental updates highlight changes, prompting immediate documentation synchronisation. Onboarding Simplified: New developers can onboard quickly, thanks to the always-current AsciiDoc artefacts. Innovation-Focused Development: By delegating boilerplate tasks to AI, developers focus their energy on problem-solving an ## The pursuit of fast feedback loops DevFeed: [The pursuit of fast feedback loops]() Original publisher: [Read original article]() Author: Saket Narayan Published: 2024-11-27T17:46:56Z Content type: opinion Language: en Sources: [Saket Narayan]() Topics: [Mobile](), [Compose](), [ui](), [unit tests](), [jetbrains]() Tags: [android](), [compose](), [hot-reloading](), [incremental](), [jetbrains](), [layout](), [mobile](), [screenshot](), [tests]() ### AI overview This opinion argues that fast feedback loops for validating software changes matter more than hot reloading itself. It discusses the reliability history of hot-reload tools and describes using screenshot tests and unit tests to shorten UI and presentation/backend iteration cycles. ### Source excerpt Sebastian Sellmair from JetBrains recently showed off a prototype of hot-reloading Compose UI code for deploying changes without rebuilding the project. It looks exciting and I want it to succeed. At the same time, I've learned to be cautiously optimistic about hot-reload solutions. Google has tried this multiple times: their first attempt (Instant Run) was [...] The post The pursuit of fast feedback loops appeared first on Saket Narayan. ## Value Statements for My New Company DevFeed: [Value Statements for My New Company]() Original publisher: [Read original article]() Author: Fuzzygroup Published: 2022-07-15T07:39:00Z Content type: opinion Language: en Sources: [Scott Johnson]() Topics: [Software](), [test-coverage](), [cloud-infrastructure](), [Support](), [unit tests](), [version-control]() Tags: [coverage](), [culture](), [distributed](), [ethics](), [github](), [software](), [startup](), [support](), [test-coverage](), [unit-tests](), [version-control](), [work-from-home]() ### AI overview The author presents draft values for a new company, emphasizing ethical behavior, written documentation, respectful communication, commitment-keeping, transparency, work-life balance, technical support, software quality, version control, and test coverage. ### Source excerpt Welp, it looks like I'm starting a new company after all. Here are the values that I drafted for it. Values These things we believe: Ethics. We will behave ethically in all situations. Writing Things Down. We will work from home and be a distributed culture. And in a distributed culture, things have to be written down. Good writing is a skill for everyone not something reserved for writing. Having the Hard Conversations Respectfully. In any culture there will be conflict. This can be done respectfully and without tripping anyone's bozo bit. Do What We Say. We will keep our commitments and do the things we say. If we fail - and that's expected - then we will apologize and accept responsibility. Openness and Transparency. Shining light on things makes the badness scurry away. That's the power of openness and transparency. Revenue Disclosure. Every organization is, correctly, driven by its revenue sources - and that's ok. Problems occur, however, when you fail to disclose your revenue sources. Ethical Capitalism. Capitalism has been the single most transforming force in history and it has done more to lift people from poverty than anything else. Now, that said, capitalism without regulation and restraint is a violent beast. The capitalism I believe in was taught to me by my grandfather and it could be summarized as "do the right thing; don't chase every dollar; pay it forward; treat everyone with kindness". Code of Conduct. We will treat each other with mutual respect. We have adoped the Github code of conduct it appends to every repo. Work Should Be Secondary to Life. This is a business but business was not supposed to take over our lives. All staff are encouraged to take acknowledge this and, hopefully, take four day work weeks as often as they like. World Class Technical Support. The high tech industry can - and should - offer world class support. Great support is possible when you have high gross margins - which is all of the technology business - although most peo ## Migrating to the new coroutines 1.6 test APIs DevFeed: [Migrating to the new coroutines 1.6 test APIs]() Original publisher: [Read original article]() Author: Márton Braun Published: 2022-06-29T20:00:00Z Content type: tutorial Language: en Sources: [zsmb.co]() Topics: [Coroutines](), [Testing](), [migration](), [unit tests]() Tags: [android](), [coroutines](), [deprecated](), [junit](), [migration](), [testing](), [unit-tests]() ### AI overview This tutorial explains how to migrate Android projects from deprecated coroutines 1.6 testing APIs to the new APIs. It covers using runTest, handling the main thread in unit tests, and testing Flow collection. ### Source excerpt See the steps we took to migrate our samples to the new APIs, and then get started on migrating your own project! ## Using Makefiles to Simplify Command-Line Test Workflows DevFeed: [Using Makefiles to Simplify Command-Line Test Workflows]() Original publisher: [Read original article]() Author: Derek Lee Published: 2022-02-19T05:00:00Z Content type: tutorial Language: en Sources: [art and science of coding]() Topics: [make](), [Command-line interface](), [test](), [unit tests](), [ci](), [iOS](), [Xcode](), [Gradle](), [JavaScript]() Tags: [automation](), [ci](), [command-line](), [communication](), [discoverability](), [gradle](), [ios](), [javascript](), [kotlin](), [make](), [science](), [simplicity](), [test](), [unit-tests]() ### AI overview This tutorial argues for using Makefiles to simplify and standardize command-line test execution across projects. It contrasts Makefiles with Fastlane and shell scripts, and begins an iOS example using Make targets to run an Xcode test suite. ### Source excerpt I make a point of always running the test suite (at least the fastest of the bunch: the unit tests) from the command line before pushing code to CI to confirm that all has gone smoothly. ## Understanding and Configuring your Kotlin Multiplatform Mobile Test Suite - Gustavo Fão Valvassori DevFeed: [Understanding and Configuring your Kotlin Multiplatform Mobile Test Suite - Gustavo Fão Valvassori]() Original publisher: [Read original article]() Published: 2022-01-11T21:22:39Z Content type: tutorial Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [Kotlin Multiplatform](), [Testing](), [Mobile](), [unit test](), [unit tests]() Tags: [article](), [how-to](), [kotlin](), [kotlin-multiplatform](), [kotlin-multiplatform-mobile](), [mobile](), [tests](), [verify]() ### AI overview This tutorial explains how to configure the test suite in a Kotlin Multiplatform Mobile project. It distinguishes Android unit and instrumented tests, describes the corresponding source sets, and contrasts them with testing on iOS, where both types run in the same target by default. ### Source excerpt Writing tests is part of every developer's day-to-day routine. They help you write better and more reliable code. In addition, they can verify that your code does what it was supposed to do, and your changes haven't introduced bugs. In this article, I'll show you how to configure the test suite from your KMM project. ## Building a test suite for the OONI Probe Android app DevFeed: [Building a test suite for the OONI Probe Android app]() Original publisher: [Read original article]() Author: Cláudia Published: 2021-09-20T11:10:34Z Content type: article Language: en Sources: [Blog - Bloco]() Topics: [Android](), [test](), [test-coverage](), [unit tests](), [ci](), [Dependency injection](), [ui]() Tags: [android](), [clients](), [code-coverage](), [continuous-integration](), [dependency-injection](), [test](), [ui](), [unit-tests]() ### AI overview This article describes work with OONI to improve the quality of its Probe Android app by building a comprehensive test suite. The work included test infrastructure, continuous integration, dependency injection, fake-data factories, UI tests, and unit tests. Over 15 days, the team wrote 43 UI tests and 201 unit tests, increasing code coverage from 10% to 73%. ### Source excerpt Let us tell you how we've worked with OONI to improve the quality of their Probe Android app. ## Kotlin-Multiplatform Shared Test Resources DevFeed: [Kotlin-Multiplatform Shared Test Resources]() Original publisher: [Read original article]() Author: Victoria Gonda Published: 2021-08-24T19:00:00Z Content type: tutorial Language: en Sources: [Square Corner Blog RSS Feed]() Topics: [Kotlin Multiplatform](), [unit tests](), [Kotlin](), [kotlin-native]() Tags: [engineering](), [kotlin](), [kotlin-multiplatform](), [unit-tests]() ### AI overview A Kotlin Multiplatform tutorial for sharing test fixtures and tests across platforms. It demonstrates reading binary protobuf test resources in JVM and iOS tests using platform-specific implementations behind a common test API. ### Source excerpt Verifying your code regardless of platform ## Experiment with Kotlin Mobile Multiplatform DevFeed: [Experiment with Kotlin Mobile Multiplatform]() Original publisher: [Read original article]() Author: Dmitry Samoylenko Published: 2021-01-22T00:00:00Z Content type: opinion Language: en Sources: [Dmitry Samoylenko - Android Developer Blog]() Topics: [multiplatform](), [Kotlin](), [Mobile](), [Android](), [iOS](), [Gradle](), [Ktor](), [Coroutines](), [CI/CD](), [unit tests]() Tags: [android](), [ci-cd](), [coroutines](), [gradle](), [ios](), [kotlin](), [ktor](), [mobile](), [multiplatform](), [unit-tests]() ### AI overview An experiment with Kotlin Multiplatform examines shared code between Android and iOS, comparing app size and outlining benefits, maintenance challenges, tooling requirements, and possible effects on developer roles. ### Source excerpt Experiment with ivi pages: ## Implementing Stable API for Apache Airflow DevFeed: [Implementing Stable API for Apache Airflow]() Original publisher: [Read original article]() Author: Apache Airflow Published: 2020-07-19T00:00:00Z Content type: article Language: en Sources: [Apache Airflow Blog]() Topics: [REST API](), [OpenAPI Specification](), [API](), [Database](), [unit tests](), [Flask]() Tags: [apache-airflow](), [api](), [implementing](), [openapi](), [rest-api](), [schema](), [tests]() ### AI overview An Outreachy intern describes progress on extending and improving the Apache Airflow REST API. The article covers read-only Connection and DagRun endpoints, database schema work with Marshmallow 2, unit tests, OpenAPI date-time validation, and workarounds for library licensing and parsing issues. ### Source excerpt My Outreachy internship is coming to its ends which is also the best time to look back and reflect on the progress so far. The goal of my project is to Extend and Improve the Apache Airflow REST API. In this post, I will be sharing my progress so far. We started a bit late implementing the REST API because it took time for the OpenAPI 3.0 specification we were to use for the project to be merged. Thanks to Kamil, who paved the way for us to start implementing the REST API endpoints. Below are the endpoints I implemented and the challenges I encountered, including how I overcame them. Implementing The Read-Only Connection Endpoints The read-only connection endpoints were the first endpoint I implemented. Looking back, I can see how much I have improved. I started by implementing the database schema for the Connection table using Marshmallow 2. We had to use Marshmallow 2 because Flask-AppBuilder was still using it and Flask-AppBuilder is deeply integrated to Apache Airflow. This meant I had to unlearn Marshmallow 3 that I had been studying before this realization, but thankfully, Marshmallow 3 isn't too different, so I was able to start using Marshmallow 2 in no time. This first PR would have been more difficult than it was unless there had been any reference endpoint to look at. Kamil implemented a draft PR in which I took inspiration from. Thanks to this, It was easy for me to write the unit tests. It was also in this endpoint that I learned using parameterized in unit tests :D. Implementing The Read-Only DagRuns Endpoints This endpoint came with its many challenges, especially on filtering with datetimes. This was because the connexion library we were using to build the REST API was not validating date-time format in OpenAPI 3.0 specification, what I eventually found out, was intentional. Connexion dropped strict-rfc3339 because of the later license which is not compatible with Apache 2.0 license. I implemented a workaround on this, by defining a function called c ## Kotlin Code Organization DevFeed: [Kotlin Code Organization]() Original publisher: [Read original article]() Author: Artur Dryomov Published: 2020-01-27T00:00:00Z Content type: tutorial Language: en Sources: [Artur Dryomov]() Topics: [Code](), [Kotlin](), [systems](), [Gradle](), [Maven](), [configuration](), [unit tests]() Tags: [code](), [configuration](), [gradle](), [kotlin](), [maven](), [organization](), [unit-tests]() ### AI overview This tutorial explains how to organize Kotlin code using standard directory layouts and source sets. It recommends separating production and test code, grouping files by language and tooling, storing Kotlin files in Kotlin-specific directories, and organizing extension functions by their target class and package. ### Source excerpt What's the motivation behind organizing the code? Two points come to mind. Help humans. Consistent environments are easier to understand and adapt. Storing the source code in src/ instead of _k_/ makes it easier to find. Help machines. Build systems need hints. The code in main/ should be assembled all the time, while test/ is test-specific and shouldn't make it to a production environment. Sounds empathic. Where do we start? ## Test naming convention DevFeed: [Test naming convention]() Original publisher: [Read original article]() Published: 2019-03-14T00:00:00Z Content type: tutorial Language: en Sources: [Paweł Chudzik]() Topics: [Automation](), [unit tests](), [Development](), [Code review]() Tags: [api](), [automated](), [automation](), [code-review](), [database](), [excel](), [ide](), [integration-test](), [tests](), [verify]() ### AI overview This tutorial explains how to use automated tests to enforce naming conventions for test groups. It distinguishes fast unit tests from integration tests involving I/O, databases, external APIs, reports, and Excel imports, and argues that convention checks can serve as both automated enforcement and living documentation. ### Source excerpt How to introduce automated checks that will guarantee that conventions are followed in an example of test naming convention. I'm going to focus on creating automated process that will verify if test names do match conventions. Automation will allow us to forget about the rule because the computer will ensure it's followed. Test that I'm going to introduce will be living documentation inside the project and ensure no one will miss nor forget about the way we group tests. Read more ## Reducing Technical Debt by Removing Development Friction DevFeed: [Reducing Technical Debt by Removing Development Friction]() Original publisher: [Read original article]() Published: 2019-02-15T00:00:00Z Content type: opinion Language: en Sources: [Dan Abramov]() Topics: [Code](), [unit tests](), [Deployment](), [bug]() Tags: [bug](), [code](), [deployment](), [features](), [performance](), [technical](), [unit-tests]() ### AI overview The article argues that technical debt includes not only visible code problems but also friction that discourages developers from investigating bugs, trusting deployment scripts, locating regressions, or experimenting. It concludes that actively reducing this friction helps prevent important work from being indefinitely postponed. ### Source excerpt The other kind of technical debt. ## Testing LiveData in JUnit 4 and JUnit 5 DevFeed: [Testing LiveData in JUnit 4 and JUnit 5]() Original publisher: [Read original article]() Author: info@jeroenmols.com (Jeroen Mols) Published: 2019-01-17T00:00:00Z Content type: tutorial Language: en Sources: [Jeroen Mols]() Topics: [Testing](), [Android](), [test](), [unit tests]() Tags: [android](), [architecture](), [architecture-components](), [blogs](), [gradle](), [junit](), [livedata](), [testing](), [unit-test](), [unit-tests](), [viewmodel]() ### AI overview A tutorial on testing Android LiveData with JUnit 4 and JUnit 5. It explains why JVM unit tests cannot use Android's main thread directly and shows how JUnit rules or JUnit 5 extensions can update LiveData synchronously on the calling thread. ### Source excerpt Architecture components are one of the most exciting things that happened to Android in the past years. But how do you effectively go about and testing this? ## Configuring JaCoCo coverage limits in Android Gradle projects DevFeed: [Configuring JaCoCo coverage limits in Android Gradle projects]() Original publisher: [Read original article]() Published: 2018-10-13T13:55:25Z Content type: tutorial Language: en Sources: [maiatoday]() Topics: [Android](), [Gradle](), [test-coverage](), [Kotlin](), [unit tests](), [Java]() Tags: [android](), [code](), [gradle](), [jacoco](), [java-8](), [kotlin](), [test-coverage](), [unit-tests]() ### AI overview A practical Android Gradle snippet that adds JaCoCo test coverage, Kotlin support, and coverage limits for selected important classes or packages. It explains how to add the configuration, run coverage verification, and find the generated HTML report. It also warns that a Robolectric-related configuration line can crash unit tests on Java versions newer than 8. ### Source excerpt I have found myself adding jacoco and coverage limits to more than one Android project. Enough times for me to extract the gradle bits in to a little nugget of grooviness to just drop into a project as needed. For a while now I have been reading about test coverage numbers and working with my intuition about what is the most valuable thing for me to spend my time on when building something. Also Kotlin. In the light of this my gradle build file snippet contains the following: Jacoco for test coverage Kotlin support A way to choose important classes and only set coverage limits on those Do this, Put the gist in a file jacoco.gradle Modify the jacoco.gradle file to add limits for your important packages. Add this line to your build.gradle apply from: 'jacoco.gradle' And then run the command ./gradlew tasks to see what new tasks are there to run. e.g. in the reporting section find something similar to ./gradlew/testDevDebugUnitTestCoverageVerification which will run the tests, make coverage reports and apply limits. Find the reports in a path similar to this ~/your\_project/your\_module/build/reports/jacoco/testDevDebugUnitTestCoverage/html/index.html Without further ado, the gist: The code in the gist was taken from so many blogposts. I can't even remember them all. Thanks to the original authors. Also note there is a small piece of cargo cult code that kept sneaking in from sundry blogposts that I don't need because I don't have Robolectric tests. As it turns out this code crashes unit tests on Java > 8. So remove this code if you have it and if it fits your usecase. tasks.withType(Test) { jacoco.includeNoLocationClasses = true } ## Unit tests on Android with Kotlin (KAD 22) DevFeed: [Unit tests on Android with Kotlin (KAD 22)]() Original publisher: [Read original article]() Published: 2017-04-25T00:00:00Z Content type: tutorial Language: en Sources: [Antonio Leiva]() Topics: [Android](), [Kotlin](), [unit tests](), [Gradle](), [Java]() Tags: [android](), [gradle](), [java](), [kotlin](), [mocking](), [tests](), [unit-tests]() ### AI overview This tutorial explains how to create and run unit tests for Android applications written in Kotlin. It covers adding JUnit and Mockito with Gradle, creating a first test, and addressing Mockito compatibility issues with Kotlin nullability and final classes. ### Source excerpt Everything Android, Kotlin and other random topics ## Extending Mockito DevFeed: [Extending Mockito]() Original publisher: [Read original article]() Author: info@jeroenmols.com (Jeroen Mols) Published: 2016-10-31T00:00:00Z Content type: tutorial Language: en Sources: [Jeroen Mols]() Topics: [Mocking](), [Java](), [unit tests](), [Framework]() Tags: [android](), [blogs](), [examples](), [framework](), [github](), [how-to](), [java](), [library](), [mastodon](), [mocking](), [mockito](), [testing](), [tests](), [unit-tests]() ### AI overview A tutorial on extending Mockito with custom argument matchers. It explains how custom matchers can simplify verification of collection contents in unit tests and mentions a GitHub library of collection matchers. ### Source excerpt Due to its clean simple api, Mockito has become world's most popular Java mocking framework. After having covered all of its basics, it's time to spice things up and start extending Mockito. ## Test methods coupling DevFeed: [Test methods coupling]() Original publisher: [Read original article]() Published: 2016-10-29T00:00:00Z Content type: opinion Language: en Sources: [Paweł Chudzik]() Topics: [unit tests](), [maintenance](), [Code]() Tags: [change](), [complexity](), [maintenance](), [unit-tests](), [verify]() ### AI overview The article explains how shared, complex setup in unit tests creates coupling and shared state across test methods. It argues that this shortcut makes tests harder to understand and maintain, especially when requirements change or bugs are investigated. ### Source excerpt Sometimes when unit tests setup is complex we are tempted to take shortcuts and write single setup for all tests which will save as few keystrokes. In the time of writing the test it might feel like a good idea to configure complex unit test setup and reuse it in all test. This way we avoid code duplication and we create a more condensed test. This approach looks good only in the time of the writing tests. Then there is a time when unit tests must be maintained. This is the time when you usually realize that saving few keystrokes wasn't such a good idea. Read more ## Curious Customer DevFeed: [Curious Customer]() Original publisher: [Read original article]() Author: Jay (noreply@blogger.com) Published: 2016-06-28T15:24:00Z Content type: opinion Language: en Sources: [Jay Fields]() Topics: [bug](), [Software](), [unit tests](), [test](), [error reporting](), [coding]() Tags: [bugs](), [context](), [customers](), [developer](), [error-reporting](), [software](), [testing](), [tests](), [unit-tests]() ### AI overview A developer reflects on how bugs triggered by nonsensical user behavior created noise, context switching, and distrust in application data despite appearing minor. The article proposes having another developer use new features in staging as a "Curious Customer" to uncover issues that conventional tests may miss. ### Source excerpt I currently work on a pretty small team, 4 devs (including myself). We have no one dedicated strictly to QA. A few years ago we ran into a few unexpected issues with our software. I hesitate to call them bugs, because they only appeared when you did things that made little sense. We write internal-only software, thus we expect a minimum level of competency from our users. In addition, it's tempting justify ignoring problematic nonsensical behavior in the name of not having to write and maintain additional software. But, when I wasn't in denial, I was willing to admit that these were in fact bugs and they were costing us time. The problems caused by these bugs were small, e.g. a burst of worthless emails, a blip in data flowing to the application. The emails could be quickly deleted, and the application was eventually consistent. Thus I pretended as though these issues were of low importance, and that the pain was low for both myself and our customers. I imagine that sounds foolish; in retrospect, it was foolish. The cost of developer context switching is often very high, higher if it's done as an interrupt. Introducing noise into your error reporting devalues your error reporting. Users can't as easily differentiate between good data, a blip of bad data due to something they did, and actual bad data, thus they begin to distrust all of the data. The cost of these bugs created by nonsensical behavior is high, much higher than the cost of writing and maintaining the software that eliminated these bugs. Once we eliminated these bugs, I spent notably more time happily focused on writing software. For me, delivering features is satisfying; conversely, tracking down issues stemming from nonsensical behavior always feels like a painfully inefficient task. I became very intent on avoiding that inefficiency in the future. The team brainstormed on how to address this behavior, and honestly we came up with very little. We already write unit tests, load tests, and integration te [Next page]()