DEV Community: Viram Choksi

The 7 Sneakiest Bugs That Slip Past 100% Test Coverage (And How to Spot Them)

Viram Choksi — Fri, 30 Oct 2026 17:36:41 +0000

We’ve all heard the myth: "If the tests are green, the code is ready for production."

Then at 11:30 PM on a Friday, an unhandled exception brings down the API.

The truth is, automated tests test the code paths you remembered to write tests for. But real-world code has sneaky language quirks, silent memory mutations, and edge cases that look 100% syntactically innocent until they meet real user data.

Here are 7 of the sneakiest bugs in modern software development—and how to spot the pattern before your users do.

1. The Reference Trap: `[[]] * 3` in Python

The Innocent Code:

# Create a 3x3 grid
grid = [[]] * 3
grid[0].append("bug")

print(grid)

What you expect:
[['bug'], [], []]

What actually happens:
[['bug'], ['bug'], ['bug']]

Why it breaks:
In Python, the * operator on a list does not make deep copies. It creates three copies of the pointer to the exact same list in memory. When you mutate grid[0], all three positions reflect the change because they are all referencing the exact same object.

The Fix:
Use a list comprehension to create independent inner lists:

grid = [[] for _ in range(3)]

2. The Iterator Shift: Mutating an Array While Looping

The Innocent Code:

nums = [2, 4, 6, 8]

for n in nums:
    nums.remove(n)

print(nums)

What you expect:
[] (An empty list)

What actually happens:
[4, 8]

Why it breaks:
Python’s loop maintains an internal index pointer.

On iteration 0, it removes 2. The list becomes [4, 6, 8].
Now, index 0 is 4, and index 1 is 6!
The loop advances to iteration 1, which reads index 1 (6), skipping 4 completely!

The Fix:
Iterate over a shallow copy (nums[:]) or use a list comprehension:

nums = [n for n in nums if not should_remove(n)]

3. The `parseInt` in `Array.prototype.map`

The Innocent Code:

const numbers = ["10", "10", "10", "10"].map(parseInt);
console.log(numbers);

What you expect:
[10, 10, 10, 10]

What actually happens:
[10, NaN, 2, 3]

Why it breaks:
Array.prototype.map passes three arguments to its callback: (element, index, array).

parseInt takes two arguments: (string, radix).

So JavaScript actually executes:

parseInt("10", 0) -> Radix 0 defaults to decimal -> 10
parseInt("10", 1) -> Radix 1 is invalid -> NaN
parseInt("10", 2) -> Radix 2 (binary 10) -> 2
parseInt("10", 3) -> Radix 3 (ternary 10) -> 3

The Fix:
Pass an explicit arrow function:

const numbers = ["10", "10", "10", "10"].map(str => parseInt(str, 10));
// Or simply:
const numbers = ["10", "10", "10", "10"].map(Number);

4. The Mutable Default Argument

The Innocent Code:

def add_user_to_cache(user, cache=[]):
    cache.append(user)
    return cache

print(add_user_to_cache("Alice"))
print(add_user_to_cache("Bob"))

What you expect:
['Alice']

['Bob']

What actually happens:
['Alice']

['Alice', 'Bob']

Why it breaks:
Python evaluates default function arguments once when the function is defined, not every time it is called. That default [] is stored in the function's __defaults__ tuple for the lifetime of the process.

The Fix:
Use None as a sentinel value:

def add_user_to_cache(user, cache=None):
    if cache is None:
        cache = []
    cache.append(user)
    return cache

5. JavaScript's Alphabetical `.sort()`

The Innocent Code:

const scores = [1, 25, 5, 100, 12];
scores.sort();
console.log(scores);

What you expect:
[1, 5, 12, 25, 100]

What actually happens:
[1, 100, 12, 25, 5]

Why it breaks:
By default, .sort() converts all elements to strings and compares their UTF-16 code units. Because "100" starts with "1", it comes before "2". Because "25" starts with "2", it comes before "5".

The Fix:
Always supply a comparator function for numeric sorting:

scores.sort((a, b) => a - b);

6. The `max()` on an Empty Sequence

The Innocent Code:

def get_highest_bid(bids):
    return max(bids)

What happens in testing:
You test with [100, 250, 40] -> Returns 250. Tests pass!

What happens in production:
A new auction opens with 0 bids. A user views the page.

Boom: ValueError: max() arg is an empty sequence.

The Fix:
Provide the default keyword argument:

def get_highest_bid(bids):
    return max(bids, default=0)

7. The Float Precision Trap

The Innocent Code:

function applyDiscount(balance) {
    if (balance === 0.3) {
        return "Special promo applied!";
    }
    return "Regular rate";
}

const balance = 0.1 + 0.2;
console.log(applyDiscount(balance));

What you expect:
"Special promo applied!"

What actually happens:
"Regular rate"

Why it breaks:
In IEEE 754 floating-point arithmetic (used by JS, Python, and most languages), 0.1 + 0.2 equals 0.30000000000000004. Exact equality comparisons on calculated floats will silently fail.

The Fix:
Compare within an epsilon:

if (Math.abs(balance - 0.3) < Number.EPSILON) {
    return "Special promo applied!";
}

The Real Skill: Reading Broken Code

Every coding platform and university course teaches you how to write code starting from line 1 of an empty file.

Nobody teaches you how to read 300 lines of legacy code at midnight, spot the silent mutation, and fix it without breaking five other things.

If you want to train your eye to spot these bugs in real time, check out TryBugHunt:

150+ interactive, real-world debugging challenges.
You get the symptom and broken code—never the answer.
Runs 100% client-side in your browser (powered by WebAssembly and Pyodide).
Includes escalating hints and mental model explanations.

It's completely free and requires zero login to start solving: trybughunt.com

What’s the most innocent-looking bug that has ever taken down your production system? Share your war stories in the comments!

Nobody teaches you to debug

Viram Choksi — Tue, 04 Aug 2026 18:42:49 +0000

You've been here.

The code looks right. It runs. The output is wrong.

No error. No stack trace. Nothing to paste into Google. Just a number that should
be 10 and is 4, and no idea where it went.

Three years of writing code, zero of fixing it

Every assignment I was given was graded on writing something from scratch.

Not one was graded on fixing something broken.

Then you get to real work and it inverts completely. You spend far more time
reading code you didn't write and finding out why it misbehaves than you ever
spend on a blank file.

We're trained for the rare case and left to improvise the common one.

Bugs aren't infinite. They're a handful of shapes

This is the thing that changed how I think about it.

Almost every bug is one of a small number of patterns:

the shape	what you see
🔁 Loop runs one time too many	`IndexError` on the last item
0️⃣ A valid `0` treated as missing	Setting it to zero has no effect
🔒 Closure captures the variable, not the value	Every callback reports the last one
📋 A "copy" that's the same object	Editing the copy changes the original

Once you can recognise the shape, you stop debugging line by line and start
recognising. The next one takes minutes instead of an afternoon.

You can't get that from reading. You get it from finding bugs, repeatedly, and
being told what you just found.

So I built the practice

BugHunt gives you working code with exactly one
bug in it.

You get the symptom, not the cause:

last_char("hello") raises IndexError: string index out of range

def last_char(text):
    return text[len(text)]     # ← one character too far

You find it. Fix it in the browser. Run it against the test cases.

When it passes, you get an explanation of the pattern — not just the diff.
Knowing this loop needed i + 1 is nearly worthless. Recognising an off-by-one
on sight is worth a lot.

A few things that matter

Nothing to install. Python runs through WebAssembly right in the tab. Works on
a locked-down college lab machine with no admin rights.

No account needed. Solve a bug, read the explanation, close the tab. An account
only saves your progress.

Watch it run. Step through line by line and see every variable at every step.
Seeing the exact moment a value goes wrong is very different from being told
where the bug was.

Free. No ads, no paywall. It runs on free hosting tiers on purpose — there's
nothing to recoup, so there's no reason to start charging.

Try one

Pick a bug and see how long it takes you:

trybughunt.com

If an explanation is confusing, there's a report button on every challenge. I
read them.

Four things that surprised me running Python in the browser

Viram Choksi — Tue, 04 Aug 2026 18:31:20 +0000

I built a debugging-practice site where student code runs entirely in the
browser. Python via Pyodide, JavaScript in a worker. No
server executes anything.

No execution bill, no queue, no sandbox to maintain. But four things bit me hard.

1. Your arguments aren't Python objects

Pass a JS object into Python and you get this:

TypeError: 'pyodide.ffi.JsProxy' object is not subscriptable

It's not a dict. It's a live view of the JS object, and it supports neither
obj[key] nor .get().

Convert explicitly:

const pyArgs = input.map((arg) => pyodide.toPy(arg));
const result = fn(...pyArgs);

2. `null` is not `None`

This one passed my entire test suite while being broken in production.

pyodide.toPy(null)

check	result
`type(v)`	`JsNull`
`bool(v)`	`False`	✅ falsy, as expected
`v is None`	`False`	❌ the surprise

It's falsy, so truthiness checks work fine. But is None fails — which was
exactly what my code was checking.

Why my tests missed it: the harness used json.loads. The app used toPy.
Different conversion paths, different answers.

If you need a real None, create it in Python. Don't pass one across.

3. `sys.settrace` is a free step debugger

Want to show users their code running line by line? Python basically hands it to you:

def _tracer(frame, event, arg):
    if frame.f_code.co_name != target:
        return None                    # skip library frames
    if event == "line":
        steps.append({
            "line": frame.f_lineno,
            "locals": dict(frame.f_locals),
        })
    return _tracer

Two things this naive version gets wrong:

Add a step cap. A tight loop generates steps faster than it burns a 5-second timeout. You need both guards.
Handle exception. During unwinding, the return event still fires with arg=None. Miss it and your trace says "returned None" for code that crashed.

4. Your snapshots are lying

A user screenshot exposed this one.

Every step in the trace showed the final state of a list. Step 1 included
mutations that hadn't happened yet.

  tracing:  nums = []; nums.append(1); nums.append(2)

- what the trace showed        + what actually happened
- step 1   nums = [1, 2]       + step 1   nums = []
- step 2   nums = [1, 2]       + step 2   nums = [1]
- step 3   nums = [1, 2]       + step 3   nums = [1, 2]

frame.f_locals gives you references. Snapshot a list and you've stored a
pointer to something the program keeps mutating.

# copy at capture time
return json.loads(json.dumps(value))

Any time you snapshot mutable state over time, you're one reference away from
a history that rewrites itself.

Worth it?

Yes. Zero execution cost, scales infinitely, works on a locked-down lab machine
with nothing installed.

But test against the real runtime. Every bug above was found by running the
actual thing — not by unit tests around it. The JsNull one passed a fully green
suite.

Built for BugHunt — free debugging practice,
runs in your browser, no account needed.

Why My Portfolio Has a Boot Sequence, Window Manager, and 6 Playable Games

Viram Choksi — Sun, 29 Mar 2026 17:19:36 +0000

I Built a Full Operating System as My Developer Portfolio — Here's How

Most developer portfolios look the same: a hero section, some cards, a contact form. I wanted mine to make recruiters stop scrolling.

So I built ViramOS — a fully functional desktop operating system that runs in the browser. Boot sequence, login screen, draggable windows, taskbar, 13+ interactive apps, 6 playable games, and a working terminal. All built with Next.js, React, and Framer Motion.

Live demo: viram-choksi.vercel.app

What Does It Actually Do?

When you visit my portfolio, you don't see a webpage. You see this:

Boot Sequence — Matrix rain, ASCII art, fake BIOS logs loading frameworks
Login Screen — Glassmorphic card with animated gradient ring, press Enter to unlock
Desktop — Animated wallpapers, floating particles, draggable app icons
Window Manager — Drag, resize, minimize, maximize, snap-to-edge (like Windows 11)
Taskbar — Running app indicators, system tray, control center, clock

And then 13+ apps you can actually use:

Terminal with 15+ commands (whoami, neofetch, benchmark, architecture)
Projects file manager with metrics and impact numbers
Skills package manager with proficiency bars
Games — Snake, 2048, Tic Tac Toe (with minimax AI), Typing Test, Memory Card, Reaction Time
System Monitor — Real-time FPS, Core Web Vitals, bundle size breakdown, architecture decision records
Settings — 12 wallpapers, accent colors, font scaling, night shift, high contrast
Command Palette — Press / to fuzzy-search and launch any app

The Tech Stack

Layer	Technology
Framework	Next.js 16 (App Router, SSR, ISR)
UI	React 19, Framer Motion
Styling	Tailwind CSS 4
3D	Three.js + React Three Fiber
State	React Context (no Redux needed)
Email	Nodemailer via API route
Analytics	Vercel Analytics + Speed Insights
Deploy	Vercel (Edge Network)

Architecture Decisions That Matter

Why React Context over Redux?

The OS state (open windows, settings, theme) is shared across components but updates infrequently — user clicks, not real-time data. Context + useCallback/useMemo keeps the bundle smaller and API simpler. Redux would add ~12KB gzipped for state that changes maybe 5 times per session.

Why DOM Windows, Not Canvas?

I considered building the window manager on Canvas (like Figma does). But DOM-based windows mean:

Native text selection inside windows
Form inputs work naturally
Screen readers can access content
Standard React component composition

Canvas would give better performance at 50+ simultaneous windows, but a portfolio never has more than 5 open.

Why Framer Motion over CSS Animations?

The boot sequence, window transitions, and desktop effects need orchestrated animations with exit transitions. CSS can't do AnimatePresence — you can't animate an element leaving the DOM. Framer Motion costs ~45KB gzipped but enables spring physics, gesture-based drag, and coordinated mount/unmount animations.

Window Snap Zones

I implemented Windows 11-style snap zones: drag a window to the left edge and it snaps to the left half, right edge for right half, top for maximize. The snap preview shows a translucent overlay while dragging near edges. Dragging a snapped window out restores it to its original size.

const getSnapZone = (clientX, clientY) => {
  const vw = window.innerWidth;
  if (clientY <= 12) return "top";     // maximize
  if (clientX <= 12) return "left";    // left half
  if (clientX >= vw - 12) return "right"; // right half
  return null;
};

Settings Persistence

All user preferences (wallpaper, accent color, font size, night shift) persist to localStorage. The trick with Next.js SSR: you can't read localStorage during server render or you get hydration mismatches. So I start with defaults, then restore from localStorage in a useEffect after mount.

SEO for a JavaScript-Heavy Portfolio

The biggest SEO challenge: the homepage is entirely JS-rendered. Google can crawl dynamic content, but it takes extra time. My approach:

sr-only content — Full text resume hidden but crawlable (same content as the interactive apps)
<noscript> fallback — Visible content for JS-disabled users and crawlers
11 static landing pages — /frontend-developer-ahmedabad, /react-developer-ahmedabad, etc. with visible content, FAQ schema, and breadcrumbs
JSON-LD structured data — 7 schemas: Person, FAQPage, WebSite, ProfessionalService, ItemList, LocalBusiness, Organization
Dynamic sitemap with proper priorities and dates

Accessibility in an OS Simulation

Building an accessible OS simulation sounds contradictory, but I took it seriously:

prefers-reduced-motion — All CSS animations respect the user preference
role="application" on the desktop, role="dialog" on windows
Skip link — Tab-accessible "Skip to desktop" link
Keyboard navigation — Tab through desktop icons, Enter/Space to open apps
aria-label on all interactive elements (window controls, taskbar, context menu)
Focus indicators — Visible focus-visible rings on all buttons
Semantic HTML — <main>, <nav>, <button> instead of <div> everywhere

WCAG compliance in my day job went from 40% to 95%. I applied the same thinking here.

Performance

Despite the visual complexity, the portfolio loads fast:

Code splitting — Each app component only loads when its window opens
Immutable cache headers — 1-year cache for JS/CSS assets
Adaptive particles — Fewer particles on mobile for 60fps
Lazy window rendering — Zero hidden DOM nodes for closed apps
Vercel Edge Network — CDN distribution + SSR

What I Learned

The OS metaphor forces you to solve real problems — Window z-index management, focus trapping, state persistence, responsive layouts for different "screen sizes" inside windows. These are the same problems production apps face.
Constraints breed creativity — A scrollable page is easy. An interactive desktop with overlapping windows, a taskbar, and 13 apps forces you to think about layout, performance, and UX simultaneously.
Recruiters spend 15-30 seconds — If they don't instantly see something interesting, they leave. The boot sequence animation buys you 5 seconds of attention. The desktop experience keeps them exploring.

Try It

Live: viram-choksi.vercel.app

Open the Terminal and type help. Try / to open the Command Palette. Play Snake. Change the wallpaper in Settings. Drag a window to the edge and watch it snap.

If you're building your own portfolio, steal the architecture — just don't copy the design. The world needs more creative portfolios and fewer Bootstrap templates.

I'm Viram Choksi, a Frontend Engineer in Ahmedabad, India. I build with React.js, Next.js, Vue.js, and TypeScript. Currently at Motadata, previously at MindInventory. Say hi at viramchoksi77166@gmail.com or find me on LinkedIn.

Tags: #webdev #javascript #react #portfolio #nextjs #frontend #career

DEV Community: Viram Choksi

The 7 Sneakiest Bugs That Slip Past 100% Test Coverage (And How to Spot Them)

1. The Reference Trap: [[]] * 3 in Python

2. The Iterator Shift: Mutating an Array While Looping

3. The parseInt in Array.prototype.map

4. The Mutable Default Argument

5. JavaScript's Alphabetical .sort()

6. The max() on an Empty Sequence

7. The Float Precision Trap

The Real Skill: Reading Broken Code

Nobody teaches you to debug

Three years of writing code, zero of fixing it

Bugs aren't infinite. They're a handful of shapes

So I built the practice

A few things that matter

Try one

Four things that surprised me running Python in the browser

1. Your arguments aren't Python objects

2. null is not None

3. sys.settrace is a free step debugger

4. Your snapshots are lying

Worth it?

Why My Portfolio Has a Boot Sequence, Window Manager, and 6 Playable Games

I Built a Full Operating System as My Developer Portfolio — Here's How

What Does It Actually Do?

The Tech Stack

Architecture Decisions That Matter

Why React Context over Redux?

Why DOM Windows, Not Canvas?

Why Framer Motion over CSS Animations?

Window Snap Zones

Settings Persistence

SEO for a JavaScript-Heavy Portfolio

Accessibility in an OS Simulation

Performance

What I Learned

Try It

1. The Reference Trap: `[[]] * 3` in Python

3. The `parseInt` in `Array.prototype.map`

5. JavaScript's Alphabetical `.sort()`

6. The `max()` on an Empty Sequence

2. `null` is not `None`

3. `sys.settrace` is a free step debugger