# unit tests Published articles for unit tests. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## tota11y - an accessibility visualization toolkit DevFeed: [tota11y - an accessibility visualization toolkit]() Original publisher: [Read original article]() Author: Khan Academy Published: 2015-06-08T22:00:00Z Content type: release Language: en Sources: [Khan Academy]() Topics: [Accessibility](), [audit](), [Testing](), [Tooling](), [browser](), [Chrome]() Tags: [accessibility](), [accessibility-testing](), [audit](), [browser](), [chrome](), [developer-tools](), [engineering](), [frontend](), [linter](), [news](), [testing](), [tests](), [tooling](), [unit-tests](), [visualization](), [web](), [web-frontend]() ### AI overview Khan Academy announces tota11y, an accessibility visualization toolkit designed to make manual accessibility testing easier for developers. The article describes its development and use of browser-based annotations to help teams understand and fix accessibility issues. ### Source excerpt By Jordan Scales Today we're releasing tota11y (on GitHub), an accessibility visualization toolkit that aims to reduce the ... Read more ## Using acceptance tests to catch regression bugs in legacy code before production DevFeed: [Using acceptance tests to catch regression bugs in legacy code before production]() Original publisher: [Read original article]() Author: Valentina Jemuović Published: 2026-09-16T07:33:58Z Content type: tutorial Language: en Sources: [Optivem Journal]() Topics: [Testing](), [Requirements](), [legacy]() Tags: [automated](), [bugs](), [e2e](), [legacy-code](), [regression](), [requirements](), [testing](), [ui](), [unit-tests]() ### AI overview This hands-on article explains why automated unit and end-to-end tests may still allow production bugs in legacy code. It presents acceptance test-driven development (ATDD), where requirements and tests describe the same observable behavior, making coverage clearer and reducing dependence on UI steps. ### Source excerpt You automated, and manual regression testing is still there. Those two facts have the same cause. ## Improving Test Coverage in the Interview Coach Application with GitHub Copilot DevFeed: [Improving Test Coverage in the Interview Coach Application with GitHub Copilot]() Original publisher: [Read original article]() Author: Aaron Powell Published: 2026-09-15T16:00:21Z Content type: tutorial Language: en Sources: [Visual Studio Blog]() Topics: [test-coverage](), [Test coverage](), [GitHub Copilot](), [App](), [Visual Studio](), [Code]() Tags: [agent](), [analysis](), [code-coverage](), [copilot](), [github-copilot](), [productivity](), [projects](), [run](), [test](), [test-coverage](), [testing](), [tests](), [unit-tests](), [visual-studio]() ### AI overview This tutorial explains how to improve test coverage in the Interview Coach application by establishing a baseline, using GitHub Copilot's Test Agent to generate unit tests, and analyzing coverage across the solution. The article reports coverage increasing from 37% to 81%. ### Source excerpt Today I want to look at how we can improve on the test coverage that we have in the Interview Coach application. This application has some unit tests in it already, but I'm sure there is room for improvement. Defining our baseline Before we start writing tests, it's a good idea to have a baseline [...] The post Today I will... improve test coverage appeared first on Visual Studio Blog. ## \[GSoC 2026\] Expanding the functionality of the Haiku Devices Application - Final Report DevFeed: [\[GSoC 2026\] Expanding the functionality of the Haiku Devices Application - Final Report]() Original publisher: [Read original article]() Author: aquamatic123 Published: 2026-08-21T15:52:01Z Content type: article Language: en Sources: [Haiku Project]() Topics: [App](), [Hardware](), [GUI](), [USB](), [configuration](), [User Experience](), [Kernel](), [Testing]() Tags: [2026](), [api](), [application](), [configuration](), [devices](), [gsoc](), [gsoc2026](), [gui](), [haiku](), [hardware](), [kernel](), [report](), [software](), [unit-tests](), [user-experience]() ### AI overview This final report describes a Google Summer of Code 2026 project that expanded Haiku's Devices application from a basic hardware list into a more capable management utility. The work added driver mapping, USB and HID descriptor inspection, packaged-driver blocking with safety checks, unit tests, alphabetical sorting, improved attribute organization, and persistent selection. ### Source excerpt Hello everyone! As Google Summer of Code 2026 comes to a close, it's time to summarize the work I've done over the summer on expanding the functionality of the Haiku Devices application. Overview Haiku's Devices application previously provided a basic list of connected hardware, but lacked the features necessary to function as a true management utility. My project aimed to transform Devices into a more capable hardware manager, allowing users to view detailed technical specifications and perform administrative tasks directly from the GUI. Over the course of the summer, I focused on implementing new visualization features, improving the user experience, and pulling more detailed hardware information directly from the system. Completed Objectives & Work Accomplished Here is a breakdown of what was accomplished this summer: Driver Mapping: Integrated the GUI with the kernel structures to display the active driver module name and its absolute path (/dev). This involved extending the device_manager module by adding a new device attribute and being able to fill that attribute when possible. Extract USB descriptors: Enhanced the application's ability to inspect USB devices. By utilizing the BUSBDevice API, the app now builds a tree with all USB attributes descending the USB hierarchy. We first loop through the configurations, then the interfaces, and finally the endpoints. The app can also display HID descriptors. State Management (Packaged Driver Blocking): Added a new GUI button to disable or re-enable packaged drivers. This required implementing the backend logic to read, modify, and write to the system's Packages configuration file. I also added safety checks to prevent users from accidentally disabling drivers essential to the system, and added warnings to guide the user through the process. Unit Tests: Although not explicitly part of my initial proposal, I took the initiative to write unit tests for the application. This was a fantastic learning experience for unders ## How a Tech Lead Encouraged Testing in Legacy Code DevFeed: [How a Tech Lead Encouraged Testing in Legacy Code]() Original publisher: [Read original article]() Author: Valentina Jemuović Published: 2026-08-04T06:02:15Z Content type: opinion Language: en Sources: [Optivem Journal]() Topics: [Test-driven development](), [legacy](), [clean-code](), [Template](), [Software Engineering]() Tags: [clean-code](), [legacy-code](), [tdd](), [tech-lead](), [training](), [unit-tests]() ### AI overview This opinion article recounts how an engineering leader struggled to introduce testing and clean-code practices across multiple companies. As a Tech Lead, the author created a testable Clean Architecture template, recruited developers who valued quality, built an initial module, and trained the team to use the approach. ### Source excerpt "We don't have time to write the code twice." ## AI Coding Tip 030 - Script Your Skills, Not Your Prompts DevFeed: [AI Coding Tip 030 - Script Your Skills, Not Your Prompts]() Original publisher: [Read original article]() Author: Maxi Contieri Published: 2026-07-31T22:54:55Z Content type: tutorial Language: en Sources: [Maximiliano Contieri - Software Design]() Topics: [Script](), [coding](), [API](), [configuration](), [Artificial Intelligence]() Tags: [ai](), [api](), [coding](), [configuration](), [how-to](), [pull-request](), [script](), [test](), [unit-tests]() ### AI overview The article recommends turning repeatable AI skill steps into tested scripts instead of relying on repeated free-form prompts. It explains that scripts improve determinism, reduce token use, keep credentials in configuration files, support retries and timeouts for API calls, and make failures easier to diagnose. The model should handle judgment calls such as selecting which script to run. ### Source excerpt TL;DR: Turn repeatable skill steps into tested scripts instead of prompts, so behavior stays deterministic and cheap. Common Mistake ❌ You ask the AI to repeat the same multi-step task through free-f ## 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. ## Angular Zoneless Unit Testing DevFeed: [Angular Zoneless Unit Testing]() Original publisher: [Read original article]() Author: Francesco Borzì Published: 2025-09-30T06:30:10Z Content type: tutorial Language: en Sources: [Daniel Glejzner]() Topics: [Angular](), [Unit testing](), [Testing]() Tags: [angular](), [articles](), [code](), [testing](), [unit-testing](), [unit-tests]() ### AI overview This tutorial explains how to adapt Angular unit tests for zoneless change detection. It recommends enabling provideZonelessChangeDetection(), avoiding unnecessary detectChanges() calls, and replacing Zone.js-dependent testing helpers as applications migrate away from Zone.js. ### Source excerpt The Future Is Zoneless -- What Can We Do Today? You've probably heard: Angular is moving toward a Zoneless future. Migrating your Angular app to run without Zone.js brings several benefits, but for medium-to-large applications, the process might not be trivial. The good ## 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 ## SMURF: Beyond the Test Pyramid DevFeed: [SMURF: Beyond the Test Pyramid]() Original publisher: [Read original article]() Author: Google Testing Bloggers (noreply@blogger.com) Published: 2024-10-15T12:22:00Z Content type: tutorial Language: en Sources: [Google Testing Blog]() Topics: [Testing](), [Mocking]() Tags: [adam-bender](), [article](), [dependency](), [flaky](), [google](), [integration](), [maintainability](), [memory](), [production](), [resources](), [speed](), [testing](), [tests](), [tott](), [unit-tests]() ### AI overview This Google Testing on the Toilet article explains why the conventional test pyramid is insufficient for growing test suites. It introduces the SMURF mnemonic--Speed, Maintainability, Utilization, Reliability, and Fidelity--as a framework for balancing testing trade-offs. ### Source excerpt This article was adapted from a Google Testing on the Toilet (TotT) episode. You can download a printer-friendly version of this TotT episode and post it in your office. By Adam Bender The test pyramid is the canonical heuristic for guiding test suite evolution. It conveys a simple message - prefer more unit tests than integration tests, and prefer more integration tests than end-to-end tests. While useful, the test pyramid lacks the details you need as your test suite grows and you face challenging trade-offs. To scale your test suite, go beyond the test pyramid. The SMURF mnemonic is an easy way to remember the tradeoffs to consider when balancing your test suite: Speed: Unit tests are faster than other test types and can be run more often--you'll catch problems sooner. Maintainability: The aggregated cost of debugging and maintaining tests (of all types) adds up quickly. A larger system under test has more code, and thus greater exposure to dependency churn and requirement drift which, in turn, creates more maintenance work. Utilization: Tests that use fewer resources (memory, disk, CPU) cost less to run. A good test suite optimizes resource utilization so that it does not grow super-linearly with the number of tests. Unit tests usually have better utilization characteristics, often because they use test doubles or only involve limited parts of a system. Reliability: Reliable tests only fail when an actual problem has been discovered. Sorting through flaky tests for problems wastes developer time and costs resources in rerunning the tests. As the size of a system and its corresponding tests grow, non-determinism (and thus, flakiness) creeps in, and your test suite is more likely to become unreliable. Fidelity: High-fidelity tests come closer to approximating real operating conditions (e.g., real databases or traffic loads) and better predict the behavior of our production systems. Integration and end-to-end tests can better reflect realistic conditions, while unit ## Ep. 11: Enhancing Go Code with Effective Application Layer Tests DevFeed: [Ep. 11: Enhancing Go Code with Effective Application Layer Tests]() Original publisher: [Read original article]() Published: 2024-07-30T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Go Language](), [Testing](), [test-coverage](), [Software Engineering]() Tags: [code-coverage](), [comprehensive-go-testing](), [context](), [context-management-go-tests](), [continuous-integration](), [debugging-go-applications](), [effective-test-organization-go](), [efficient-go-testing-techniques](), [error-handling](), [go](), [go-application-layer-tests](), [go-authentication-tokens](), [go-continuous-integration-testing](), [go-dependencies-management](), [go-error-handling-consistency](), [go-middleware-handlers](), [go-project-test-implementation](), [go-subtests-domain-level](), [go-testing-strategies](), [maintaining-go-software-quality](), [mock-apis-go-testing](), [reliable-go-codebase](), [resilient-go-application](), [scalable-go-software-systems](), [table-driven-tests](), [table-driven-tests-go](), [testing](), [tests](), [unit-tests]() ### AI overview Episode 11 of the Ultimate Software Design series explains how to implement application-layer tests in Go. It covers domain-level test organization, subtests, table-driven tests, mock APIs, dependency management, authentication tokens, context, and consistent error handling, with the goal of broad coverage using minimal database instances. ### Source excerpt Introduction: Welcome to Episode 11 of our Ultimate Software Design series! In this episode, Bill delves into the intricacies of implementing robust application layer tests within Go projects, providing developers with essential strategies for creating scalable and maintainable software systems. Implement application layer tests that ensure comprehensive coverage with minimal database instances. Organize tests at the domain level using subtests for easier issue isolation and resilient code. Manage dependencies, authentication tokens, and context for smooth information flow and consistent error handling. ## Prefer Narrow Assertions in Unit Tests DevFeed: [Prefer Narrow Assertions in Unit Tests]() Original publisher: [Read original article]() Author: Google Testing Bloggers (noreply@blogger.com) Published: 2024-04-04T12:47:00Z Content type: tutorial Language: en Sources: [Google Testing Blog]() Topics: [Testing](), [Database](), [Front end]() Tags: [article](), [bugs](), [frontend](), [kai-kent](), [testing](), [tests](), [tott](), [unit-tests]() ### AI overview The article explains why broad equality assertions can make unit tests brittle by checking unrelated behavior. It recommends narrow assertions that verify only the relevant field or behavior, while reserving full-equality tests for cases that intentionally cover all related behaviors. It also briefly applies the principle to frontend unit tests. ### Source excerpt This article was adapted from a Google Testing on the Toilet (TotT) episode. You can download a printer-friendly version of this TotT episode and post it in your office. by Kai Kent Your project is adding a loyalty promotion feature, so you add a new column CREATION_DATE to the ACCOUNT table. Suddenly the test below starts failing. Can you spot the problem? TEST_F(AccountTest, UpdatesBalanceAfterWithdrawal) { ASSERT_OK_AND_ASSIGN(Account account, database.CreateNewAccount(/*initial_balance=*/5000)); ASSERT_OK(account.Withdraw(3000)); const Account kExpected = { .balance = 2000, /* a handful of other fields */ }; EXPECT_EQ(account, kExpected); } You forgot to update the test for the newly added column; but the test also has an underlying problem: It checks for full equality of a potentially complex object, and thus implicitly tests unrelated behaviors. Changing anything in Account, such as adding or removing a field, will cause all the tests with a similar pattern to fail. Broad assertions are an easy way to accidentally create brittle tests - tests that fail when anything about the system changes, and need frequent fixing even though they aren't finding real bugs. Instead, the test should use narrow assertions that only check the relevant behavior. The example test should be updated to only check the relevant field account.balance: TEST_F(AccountTest, UpdatesBalanceAfterWithdrawal) { ASSERT_OK_AND_ASSIGN(Account account, database.CreateNewAccount(/*initial_balance=*/5000)); ASSERT_OK(account.Withdraw(3000)); EXPECT_EQ(account.balance, 2000); } Broad assertions should only be used for unit tests that care about all of the implicitly tested behaviors, which should be a small minority of unit tests. Prefer to have at most one such test that checks for full equality of a complex object for the common case, and use narrow assertions for all other cases. Similarly, when writing frontend unit tests, use one screenshot diff test to verify the layout of your UI, but test ind ## Increase Test Fidelity By Avoiding Mocks DevFeed: [Increase Test Fidelity By Avoiding Mocks]() Original publisher: [Read original article]() Author: Google Testing Bloggers (noreply@blogger.com) Published: 2024-02-27T18:43:00Z Content type: tutorial Language: en Sources: [Google Testing Blog]() Topics: [Testing](), [Mocking](), [Software Engineering](), [Database](), [API]() Tags: [andrew-trenk](), [article](), [bugs](), [code](), [database](), [dillon-bly](), [in-memory-database](), [software](), [software-engineering](), [testing](), [tests](), [tott](), [unit-tests]() ### AI overview This Google Testing on the Toilet article explains that test fidelity is higher when tests use the real dependency implementation. If that is impractical, it recommends using a fake, such as an in-memory database, and using a mock only when neither a real implementation nor a fake is suitable. Mocks can reduce fidelity because their inline behavior may diverge from the real dependency. ### Source excerpt This article was adapted from a Google Testing on the Toilet (TotT) episode. You can download a printer-friendly version of this TotT episode and post it in your office. By Andrew Trenk and Dillon Bly Replacing your code's dependencies with mocks can make unit tests easier to write and faster to run. However, among other problems, using mocks can lead to tests that are less effective at catching bugs. The fidelity of a test refers to how closely the behavior of the test resembles the behavior of the production code. A test with higher fidelity gives you higher confidence that your code will work properly. When specifying a dependency to use in a test, prefer the highest-fidelity option. Learn more in the Test Doubles chapter of the Software Engineering at Google book. Try to use the real implementation. This provides the most fidelity, because the code in the implementation will be executed in the test. There may be tradeoffs when using a real implementation: they can be slow, non-deterministic, or difficult to instantiate (e.g., it connects to an external server). Use your judgment to decide if a real implementation is the right choice. Use a fake if you can't use the real implementation. A fake is a lightweight implementation of an API that behaves similarly to the real implementation, e.g., an in-memory database. A fake ensures a test has high fidelity, but takes effort to write and maintain; e.g., it needs its own tests to ensure that it conforms to the behavior of the real implementation. Typically, the owner of the real implementation creates and maintains the fake. Use a mock if you can't use the real implementation or a fake. A mock reduces fidelity, since it doesn't execute any of the actual implementation of a dependency; its behavior is specified inline in a test (a technique known as stubbing), so it may diverge from the behavior of the real implementation. Mocks provide a basic level of confidence that your code works properly, and can be especially use ## Essential Components of an Android Developer GitHub Showcase Project DevFeed: [Essential Components of an Android Developer GitHub Showcase Project]() Original publisher: [Read original article]() Author: Ban Markovic Published: 2024-02-05T11:00:04Z Content type: tutorial Language: en Sources: [Stories by Ban Markovic on Medium]() Topics: [Android](), [android-development](), [Mobile](), [Kotlin](), [REST API](), [Coroutines](), [Dependency injection]() Tags: [android](), [android-development](), [androiddev](), [coroutines](), [dependency-injection](), [github](), [jetpack-compose](), [kotlin](), [mvi](), [mvvm](), [portfolio](), [rest-api](), [screen](), [unit-tests]() ### AI overview The article recommends building a concise Android showcase project for a GitHub portfolio. The project should use two screens to fetch and display a list from a REST API, support navigation to item details, demonstrate MVI or MVVM architecture, organize files clearly, handle asynchronous work, include unit tests, and use dependency injection. ### Source excerpt In the competitive world of Android development, having a strong GitHub portfolio is crucial for showcasing your skills to potential employers. One effective way to demonstrate your expertise is by creating a concise yet comprehensive project that highlights key aspects of Android development. In this article, we'll explore the essential components that every Android developer should have in their GitHub, focusing on a project that encapsulates fundamental skills. The Project Overview A successful showcase project should include two screens and cover the following key functionalities: Fetching and Displaying Data - Utilize a REST API to fetch a list of items. - Display this list on the first screen of the app. Navigation and Detailed Information - Enable users to navigate to a second screen by clicking on a specific item. - On the second screen, display more detailed information about the selected item. Key Considerations for the Showcase ProjectArchitecture -- MVI or MVVM Clearly implement and showcase your understanding of the chosen architecture (MVI or MVVM). Organize code files in a logical and easily understandable structure. File Organization Demonstrate a well-organized project structure, separating concerns and making codebase easily maintainable (feature-based or type-based folders structure). Asynchronous Communication Showcase your proficiency in handling asynchronous tasks by using an appropriate library (e.g., Kotlin Coroutines, LiveData, RxJava). Unit Tests Impress potential employers by including unit tests to validate the functionality of critical components (cover your ViewModel, UseCase, Repository classes with unit tests). Dependency Injection (DI): Implement and demonstrate your use of dependency injection for managing component dependencies (Hilt, Dagger, Koin). Why This Project Matters This concise project effectively showcases your abilities in: Displaying a list of items Fetching data from the internet Implementing navigation between screens ## Contextual logging in Kubernetes 1.29: Better troubleshooting and enhanced logging DevFeed: [Contextual logging in Kubernetes 1.29: Better troubleshooting and enhanced logging]() Original publisher: [Read original article]() Author: The Kubernetes Authors Published: 2023-12-20T17:30:00Z Content type: release Language: en Sources: [Kubernetes Contributors Blog]() Topics: [Kubernetes](), [Logging](), [Instrumentation](), [telemetry]() Tags: [go-test](), [instrumentation](), [kubernetes](), [logging](), [logs](), [tests](), [troubleshooting](), [unit-tests]() ### AI overview The article announces that Kubernetes contextual logging, introduced in Kubernetes v1.24, has been migrated to kube-scheduler, kube-controller-manager, and some directories. Based on the go-logr API, the feature passes logger instances through callers to support structured logs with additional context, improving troubleshooting and test output in parallel applications. ### Source excerpt On behalf of the Structured Logging Working Group and SIG Instrumentation , we are pleased to announce that the contextual logging feature introduced in Kubernetes v1.24 has now been successfully migrated to two components (kube-scheduler and kube-controller-manager) as well as some directories. This feature aims to provide more useful logs for better troubleshooting of Kubernetes and to empower developers to enhance Kubernetes. What is contextual logging? Contextual logging is based on the go-logr API. The key idea is that libraries are passed a logger instance by their caller and use that for logging instead of accessing a global logger. The binary decides the logging implementation, not the libraries. The go-logr API is designed around structured logging and supports attaching additional information to a logger. This enables additional use cases: The caller can attach additional information to a logger: WithName adds a "logger" key with the names concatenated by a dot as value WithValues adds key/value pairs When passing this extended logger into a function, and the function uses it instead of the global logger, the additional information is then included in all log entries, without having to modify the code that generates the log entries. This is useful in highly parallel applications where it can become hard to identify all log entries for a certain operation, because the output from different operations gets interleaved. When running unit tests, log output can be associated with the current test. Then, when a test fails, only the log output of the failed test gets shown by go test. That output can also be more verbose by default because it will not get shown for successful tests. Tests can be run in parallel without interleaving their output. One of the design decisions for contextual logging was to allow attaching a logger as value to a context.Context. Since the logger encapsulates all aspects of the intended logging for the call, it is part of the context, ## Using Python AST to resolve dependencies DevFeed: [Using Python AST to resolve dependencies]() Original publisher: [Read original article]() Published: 2023-06-30T00:00:00Z Content type: tutorial Language: en Sources: [Gaurav Sarma's Blog]() Topics: [Python](), [Parsing](), [syntax](), [modules](), [Code]() Tags: [article](), [ast](), [code](), [dependencies](), [how-to](), [import](), [modules](), [object](), [python](), [python-dependencies](), [repository](), [resolver](), [startup](), [syntax](), [tokens](), [trees](), [unit-tests]() ### AI overview This tutorial explains how to use Python's Abstract Syntax Trees to resolve dependencies among objects imported across modules in a complex repository. It proposes recursively analyzing imports and copying required object code and dependencies into a destination folder. ### Source excerpt This article covers how to resolve python dependencies using Python's Abstract Syntax Trees (AST). There are different and maybe better ways to understand the scope of your python dependencies... ## Retry flaky tests with dotnet test and PowerShell DevFeed: [Retry flaky tests with dotnet test and PowerShell]() Original publisher: [Read original article]() Author: {"twitter"=\>"hlaueriksson"} Published: 2023-03-26T19:00:00Z Content type: tutorial Language: en Sources: [Henrik Lau Eriksson]() Topics: [PowerShell](), [.NET](), [Command-line interface](), [Smoke Tests](), [Playwright](), [Selenium]() Tags: [c-sharp](), [cli](), [configuration](), [dotnet](), [flaky](), [jenkins](), [mstest](), [nunit](), [playwright](), [powershell](), [retry](), [selenium](), [test](), [testing](), [unit-tests](), [xunit]() ### AI overview This tutorial presents a PowerShell script that uses dotnet test and TRX result files to track failed tests, retry them, report the final result, and allow a configured percentage of failures. It demonstrates the script with NUnit, MSTest, and xUnit. ### Source excerpt Introducing test.ps1, a script for running flaky tests - Keeps track of failing tests and retries them - Notifies the test framework of the current retry iteration - Makes it possible to accept a certain percentage of failing tests - Outputs the test result in a coherent way ## Table driven tests in Go DevFeed: [Table driven tests in Go]() Original publisher: [Read original article]() Published: 2023-01-19T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Go Language](), [test]() Tags: [documentation](), [go](), [go-test](), [golang](), [how-to](), [learn](), [table-driven-tests](), [tests](), [tips](), [unit-tests](), [video]() ### AI overview A video tutorial explains table-driven tests in Go and shows how sub-tests can make failing cases easier to identify when testing many inputs. ### Source excerpt Introduction Table tests are a great way to test different inputs and associated outputs for a function in Go. To write a table test, you define a slice of some data struct with fields of the input data you'll need and the expected outcome. Then you can loop through this slice and pass the data stored for each element to your function. One disadvantage of table tests is as the data set in your slice grows, the harder it is to find the failing case. Luckily, Miki will share some tips to manage this with the Go test suite. ## Parallelizing Jest and Cypress.io Tests on CircleCI DevFeed: [Parallelizing Jest and Cypress.io Tests on CircleCI]() Original publisher: [Read original article]() Published: 2022-09-07T00:00:00Z Content type: tutorial Language: en Sources: [Artsy]() Topics: [Jest](), [Cypress](), [ci](), [Developer experience]() Tags: [ci](), [circleci](), [cypress](), [developer-experience](), [jest](), [tests](), [unit-tests]() ### AI overview This tutorial explains how to parallelize CI test workloads using Jest sharding and CircleCI's split command for Cypress.io integration tests. It describes dividing Jest tests into buckets so separate processes can run subsets concurrently, reducing overall test execution time and developer wait time. ### Source excerpt At Artsy, exploring ways to improve the developer experience is part of our makeup. Whether it's implementing hot-swapping for Express.js or integrating the Rust-based SWC compiler into our front-end build pipeline, we're always trying to reduce the amount of time it takes for a code cycle to take place. CI is no exception. When a developer opens a PR, we want to ensure they get timely feedback. Do their unit tests pass? Does the app build correctly? And how about smoke tests? Each of these jobs are complex processes that take time, and the more one can parallelize said tasks the less devs will need to wait. Scaled out to a whole engineering org, minor improvements to CI can be radical. In this regard, two things came across our radar recently that we'd like to share: sharding via Jest, and a (free) way to parallelize Cypress.io integration tests via CircleCI's split command. Sharding in Jest "What is sharding?" Good question! In short, it means "a small part of a whole". The database community has employed sharding techniques for decades, where a large database is split up into smaller, more manageable chunks, usually to improve performance at scale. The same idea can be applied to any process or task involving a lot of data, including tests. Think about it like this. Imagine an app that has thousands of tests. One can open up their terminal and run yarn test and execute all of the tests at once in a single process, or one can open two terminal tabs and run yarn test src/utils and yarn test src/routes, and have both processes allocate a pool of memory to complete each (smaller) subset of tasks. Because each process has its own memory pool the performance characteristics are generally better, and thus the overall time required to run our tests is reduced / decreased. Running each of these commands scoped to a particular folder is easy enough, but in a CI environment this is somewhat cumbersome; we'd need to define two new jobs and then the conditions in which they r ## Apollo Kotlin: New Multiplatform Memory Manager DevFeed: [Apollo Kotlin: New Multiplatform Memory Manager]() Original publisher: [Read original article]() Author: Benoit Lubek Published: 2022-08-09T12:05:22Z Content type: news Language: en Sources: [Apollo Blog]() Topics: [Kotlin Multiplatform](), [kotlin-multiplatform-libraries](), [Concurrency]() Tags: [apollo](), [concurrency](), [immutability](), [kotlin](), [kotlin-multiplatform](), [kotlin-native](), [library](), [mobile](), [multiplatform](), [multithreading](), [performance](), [unit-tests]() ### AI overview Apollo Kotlin 3.5.0 adopts Kotlin Native's new memory manager. The change removes several threading and immutability restrictions, including the requirement to access the library exclusively from the Main thread on Apple targets. Initial benchmarks indicate performance improvements of up to 45%. ### Source excerpt Back in May, we shared about how Apollo Kotlin started supporting the Hierarchical project structure. Following the Kotlin Multiplatform ecosystem, here is some more news, this time about the new Memory Manager. Kotlin Native's Memory Manager Since its early days, Kotlin Native has had specific rules regarding multithreading and immutability: - objects could only be accessed from the thread they were created in - unless they had been "frozen", in which case they could be accessed by multiple... ## Instantiate test data with Instantiator DevFeed: [Instantiate test data with Instantiator]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2022-08-05T09:00:00Z Content type: tutorial Language: en Sources: [Hannes Dorfmann]() Topics: [Testing](), [unit test](), [Kotlin](), [Android](), [data](), [Library](), [Tool]() Tags: [android](), [data](), [kotlin](), [library](), [testing](), [tool](), [unit-tests]() ### AI overview The article introduces Instantiator, a Kotlin library that uses reflection to fill objects with random test data. It is presented as a way to reduce the effort of creating test data for unit tests involving transformed backend data, pagination, and nested data classes. ### Source excerpt I have noticed that most of the unit tests I write are testing how my code transforms data or business logic. My class or business logic just needs data as input (thus I need some test data to write unit tests). For example, most of my android apps load a list of items from the backend and then the android app is transforming that data into some state object or front-end specific domain objects. ## 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 [Next page]()