Search
30 results for “testing”
Search results
Testing Python with pytest
How pytest's fixture system and plain-assert philosophy replace unittest's boilerplate, and why fixture scope is the setting most likely to cause confusing test failures.
Why is an evaluation suite necessary before shipping a prompt change, instead of just testing it manually on a few examples?
A prompt change can improve one success dimension while quietly breaking another, better accuracy but worse consistency, or improved tone at the cost of latency, and manually eyeballing a handful of examples won't reliably catch a regression on a dimension you weren't specifically looking at. An evaluation suite tests against a defined, ideally large set of cases, including deliberately hard edge cases like sarcasm or mixed sentiment, and scores every dimension that actually matters, which turns "it feels better" into a measurable, defensible, trackable claim, and catches regressions before they reach production rather than after.
Azure Web App Zero-Downtime Deployment: A Hands-On Guide to Deployment Slots, Auto Scaling, and Load Testing
A practical Azure App Service lab covering staging slots, slot swaps, autoscaling, and traffic testing.
What is a pytest fixture, and what problem does it solve compared to manual setup/teardown?
A fixture is a function decorated with `@pytest.fixture` that provides a reusable piece of test setup (a database connection, a temp directory, a configured client) which pytest automatically injects into any test function that declares it as a parameter. It solves the same problem as `unittest`'s `setUp`/`tearDown` methods, but as small, composable, independently reusable functions rather than one monolithic method per test class, a test can request exactly the fixtures it needs, and fixtures can depend on other fixtures, building up complex setup from simple, testable pieces.
What is fixture scope, and why is choosing the wrong one a common source of confusing test failures?
Scope (`function`, `class`, `module`, `session`) controls how often a fixture is torn down and recreated, `function` scope (the default) creates a fresh instance for every test, while `session` scope creates it once for the entire test run and shares it across every test that requests it. Choosing a broader scope than a fixture's state can safely support is a common bug: a `session`-scoped fixture holding mutable state (like a database connection with data inserted by one test) leaks that state into every other test sharing it, causing tests to pass or fail depending on run order, a difficult, non-deterministic failure to debug.
Why does pytest let you write plain `assert x == y` instead of `self.assertEqual(x, y)`?
pytest rewrites plain `assert` statements at import time (assertion rewriting) to capture detailed information about the values on both sides of the comparison, so a failure produces a rich diff-style output, showing exactly what `x` and `y` were, without needing a specialized method per comparison type. `unittest`'s `assertEqual`/`assertTrue`/`assertIn` family exists because plain asserts in Python normally give a bare, uninformative failure message; pytest's import-time rewriting makes that special-casing unnecessary, letting tests read as ordinary Python while still producing informative failures.
Regex Tester
Test a regular expression against sample text with live match highlighting and capture groups; runs entirely in your browser.
Two transactions each update two of the same two accounts, but in opposite order, and deadlock. What's the actual fix, not just for this pair of transactions, but for the application generally?
The deadlock happens because Transaction 1 locks account A then waits for account B, while Transaction 2 locks account B then waits for account A, a circular wait. The general fix isn't retry logic alone, retries only paper over deadlocks that keep recurring, it's acquiring locks on multiple objects in the same, consistent order everywhere in the application (for example, always locking accounts in ascending id order), which makes the circular-wait pattern structurally impossible rather than merely less frequent. Retry logic is still worth having as a safety net, but consistent lock ordering is what actually eliminates this class of deadlock.
Why would you add a second disk to an existing volume group instead of just creating a new, separate filesystem on it?
Adding a disk as a new physical volume to an existing volume group extends that VG's total capacity, which lets an existing logical volume (and the filesystem on it) be grown into the new space without unmounting it, moving data, or changing the mount point the rest of the system already depends on. Creating a second, separate filesystem on the new disk instead means the original filesystem is still capacity-constrained by its original disk, and anything needing more room has to be manually split or migrated across two independent mount points rather than one that simply grew.
Why does `ping` succeeding not guarantee an application on that host is reachable?
ping tests only ICMP echo reachability at the network layer; it confirms a host responds to the network, nothing about any specific service running on it. An application listening on a TCP port can be down, crashed, or blocked by a firewall rule that specifically targets that port while still allowing ICMP through, or conversely ICMP itself can be blocked while the actual service is reachable. Confirming an application is actually up requires testing the application layer directly, e.g. `curl` against its port or `ss -tulpn` to confirm something is listening at all.
What is the difference between Layer 4 and Layer 7 load balancing?
A Layer 4 load balancer operates at the transport layer, routing based on IP address and port without inspecting the actual request content; it is fast and protocol-agnostic but cannot route based on things like URL path or headers. A Layer 7 load balancer operates at the application layer, so it can inspect HTTP requests and route based on path, host header, cookies, or content type, more flexible (path-based routing, A/B testing, session affinity by cookie) but with more per-request processing overhead.
What is the difference between SAST, SCA, and DAST, and where does each run in a pipeline?
SAST (static application security testing) analyzes an application's own source code without running it, catching issues like injection-prone patterns early in the build stage, before an artifact even exists. SCA (software composition analysis) scans a project's third-party dependencies against known-vulnerability databases, since most of a modern application's code is dependencies, not code the team wrote itself. DAST (dynamic application security testing) tests a running instance of the application from the outside, the way an attacker would, and so it runs later, typically against a deployed staging environment, after the artifact exists and is running somewhere.
Python Developer Roadmap
From syntax and data structures through tooling, testing, async programming, and web frameworks, the core path for a working Python developer, linked into Cloud Tech by Victor topic references.
How to Configure Secure File System Management with NTFS Permissions and Mapped Drives in a Windows Server Domain (Lab Guide)
This lab demonstrates how to design and implement secure file system management in a domain environment using Active Directory, Windows Server 2019, and Hyper V. The focus is on enterprise style file sharing, using NTFS permissions, group based access control, and mapped network drives, all aligned…
How does the sidecar proxy pattern actually intercept traffic without changing application code?
A sidecar proxy (typically Envoy) runs as a second container inside the same Pod as the application, sharing its network namespace. Traffic rules (usually iptables rules injected automatically by the mesh's admission controller) transparently redirect all inbound and outbound traffic through that proxy before it reaches or leaves the application container. The application still just makes normal HTTP/gRPC calls to `localhost` or a service DNS name, it has no idea a proxy is involved, which is exactly what makes the mesh's capabilities (mTLS, retries, observability) apply uniformly without any code changes.
Why is the CAP theorem often described as "choose two of three," and why is that framing slightly misleading?
The framing suggests a system designer picks any two of consistency, availability, and partition tolerance as a free, standing choice, but partition tolerance isn't actually optional for a real distributed system, network partitions happen (a link fails, a node becomes unreachable), so a system that "chooses" not to tolerate partitions simply isn't distributed in any meaningful sense once one occurs. The real choice CAP describes is narrower and only activates during an actual partition: when nodes can't communicate, do you keep responding and risk inconsistency (AP), or do you pause and refuse some requests to guarantee consistency (CP)? Outside of an actual partition, a well-designed system can be both consistent and available; CAP is a statement about what happens specifically during a partition, not a permanent, constant trade-off.
How to Add a Secondary Domain Controller to an Existing Domain (Hyper-V Lab)
As part of strengthening an Active Directory Domain Services (AD DS) environment, this lab demonstrates how to add a secondary (additional) Domain Controller to an existing domain hosted on Windows Server using Hyper V. The objective is to introduce redundancy, replication, and improved availabilit…
What does hashed sharding trade away in exchange for fixing the monotonic-key hot-shard problem?
Hashed sharding computes a hash of the shard key value and assigns chunks by hash range instead of by the raw value, which scatters even monotonically increasing keys roughly evenly across shards, since consecutive input values hash to essentially unrelated output values. The trade-off is range-query locality: a query filtering a range of the original shard key values (like "the last 24 hours" on a timestamp key) can no longer be routed to one contiguous set of shards, because the corresponding hashed values are scattered unpredictably across the whole cluster, turning what would have been a single-shard query under range sharding into a broadcast query touching every shard.
Why does BFS guarantee the shortest path in an unweighted graph, while DFS gives no such guarantee at all?
Because BFS processes vertices in strict order of distance from the start (via its queue, level by level), the first time it reaches any given vertex is necessarily via a shortest path to it, there's no way to discover a vertex at distance k before every vertex at distance k-1 has already been discovered. DFS has no such ordering property, it commits to going as deep as possible down one path before backtracking, so it can easily reach a target vertex via a long, winding path long before it would have found a much shorter one, there's nothing in DFS's structure that favors shorter paths over longer ones at all.
If no NetworkPolicy exists in a namespace, what traffic is allowed between pods, and what changes the moment one NetworkPolicy is applied?
With no NetworkPolicy at all, pods are non-isolated: every pod can send and receive traffic from any other pod, with no restriction in either direction. The moment any NetworkPolicy selects a pod for a given direction (ingress or egress), that pod becomes isolated for that direction specifically, and only the traffic explicitly allowed by an applicable policy's rules gets through from then on; unrelated pods elsewhere in the cluster that no policy selects remain fully open. This is why introducing NetworkPolicy incrementally, rather than all at once, tends to break things: the first policy applied to a namespace can silently cut off traffic nobody had previously needed to declare.
A process creates a file requesting mode 0666, but the file ends up with permissions 0644. What decided that, and would the outcome change if the parent directory had a default ACL?
The process's umask is what changed the requested mode: umask 022 turns off the write bit for group and others from any requested mode, so 0666 (rw-rw-rw-) becomes 0666 & ~022 = 0644 (rw-r--r--). The umask is applied by the kernel at file/directory creation time, not by the application deciding to be conservative. If the parent directory has a default ACL set, that changes the outcome: default ACL inheritance takes precedence over the umask entirely, so the new file's permissions would instead be derived from the ACL, not from applying umask to the requested mode.
An O(n^2) sort can be faster than an O(n log n) sort for small inputs. Why, and why doesn't that matter for a general-purpose sort function?
Big O describes asymptotic growth, not actual runtime, and O(n^2) algorithms often have smaller constant factors and simpler inner loops (no recursion or merge-buffer overhead) that make them genuinely faster in wall-clock time for small n, even though the more sophisticated O(n log n) algorithm would eventually win as n grows. This is exactly why production sort implementations, including Timsort, special-case small subarrays with a simple insertion sort internally rather than using the full merge-sort machinery on tiny inputs, getting the best of both regimes instead of picking one algorithm for every input size.
For a sorted list [1, 2, 2, 2, 3], what index does bisect_left(2) return versus bisect_right(2), and why are they different?
`bisect_left` returns 1, the insertion point before every existing 2, so inserting there keeps all 2s together immediately after it. `bisect_right` returns 4, the insertion point after every existing 2, keeping all 2s together immediately before it. They differ because they define the insertion point by a different partition rule, `bisect_left` guarantees everything before the returned index is strictly less than the target, `bisect_right` guarantees everything before the returned index is less than or equal to it, so the choice determines whether a new equal-valued element gets inserted before or after existing equal elements, not just where "some 2" is found.
What are the five stages of the browser rendering pipeline, and which ones does a change to a property like width actually have to go through?
The pipeline runs JavaScript, Style calculation, Layout, Paint, and Composite, in that order. Changing a property that affects geometry, `width`, `height`, `position`, forces the browser through every stage: layout has to be recalculated (since the element's size or position changed), then paint (since pixels changed), then composite. That full path is why layout-affecting properties are the most expensive to animate, every frame re-runs the whole pipeline, not just a cheap final step.
How does consistent hashing (a ring hash) avoid that near-total remapping problem?
Instead of computing `hash(key) % N`, both hosts and keys are hashed onto positions on a fixed conceptual ring (typically the hash function's full output range), and each key is assigned to the next host found by walking clockwise from the key's position. Removing a host only affects the keys that were mapped to that specific host's section of the ring, they get reassigned to the next host further along, while every other key on the ring, owned by a different host's section entirely, is completely unaffected. For a ring hash across N hosts, adding or removing one host affects only about 1/N of the total keys, not nearly all of them.
What is the difference between the working directory, the staging area, and a commit in Git?
The working directory is the actual files on disk, whatever state you've left them in. The staging area (the "index") is a snapshot of exactly what will go into the next commit; `git add` copies changes from the working directory into it, one file or hunk at a time, which is why you can commit only part of what you've changed. A commit is a permanent, immutable snapshot of the staging area at the moment you ran `git commit`, plus a pointer to its parent commit, which is what forms the project's history graph. Understanding that staging is a separate, explicit step - not just "what's changed" - explains why `git status` shows both staged and unstaged changes for the same file.
In the token bucket algorithm, what do the "rate" and "burst" settings each actually control?
The rate is how many tokens get added to the bucket per second, the steady-state throughput the API is designed to sustain indefinitely. The burst is the bucket's total capacity, the maximum number of tokens that can accumulate and therefore the largest spike of concurrent requests the API will accept in a single instant before it starts rejecting anything further. A request consumes one token; as long as the bucket has a token available, the request proceeds immediately, rate and burst are two independent numbers, not one combined setting, because sustained throughput and tolerance for short spikes are genuinely different things to configure.
Step-by-Step Guide: Creating a Client Computer and Joining It to a Domain (Hyper-V Lab Setup)
As part of building a realistic domain based environment, this lab demonstrates how to create a client computer and join it to an existing Active Directory Domain Services (AD DS) domain hosted on Windows Server 2019 , using Hyper V. A domain environment is incomplete without client machines. Joini…
When would you choose Azure App Service over a Virtual Machine for hosting a web application?
App Service is a fully managed PaaS; it handles OS patching, runtime installation, and built-in scaling and deployment slots, so you only manage application code and configuration. A Virtual Machine is IaaS, full control over the OS and everything installed on it, but you own patching, scaling configuration, and availability yourself. Choose App Service when the workload is a standard web app/API in a supported runtime and the team wants to minimize operational burden; choose a VM when you need OS-level control, unsupported runtimes/dependencies, or specific compliance requirements that mandate managing the host directly.
What is layout thrashing, and why does writing then reading a layout property in a loop specifically cause it?
Layout thrashing happens when code alternates writing a style (which invalidates the current layout) and reading a layout-dependent property like `offsetWidth` (which forces the browser to immediately recalculate layout synchronously to answer that read accurately), repeated across many elements in a loop. Each read-after-write pair forces a fresh, synchronous layout recalculation instead of letting the browser batch and defer that work to its normal rendering schedule, because the code demanded an up-to-date value mid-loop. The fix is mechanical: batch every write first, then batch every read afterward, so layout is only recalculated once instead of once per element.