JSJ 341: Testing in JavaScript with Gil Tayar

JSJ 341: Testing in JavaScript with Gil Tayar

Panel:
  • Aimee Knight
  • AJ O’Neal
  • Charles Max Wood
Special Guest: Gil Tayar In this episode, the panel talks with Gil Tayar who is currently residing in Tel Aviv and is a software engineer. He is currently the Senior Architect at Applitools in Israel. The panel and the guest talk about the different types of tests and when/how one is to use a certain test in a particular situation. They also mention Node, React, Selenium, Puppeteer, and much more!Show Topics:0:00 – Advertisement: KENDO UI 0:35 – Chuck: Our panel is AJ, Aimee, myself – and our special guest is Gil Tayar. Tell us why you are famous!1:13 – Gil talks about where he resides and his background. 2:27 – Chuck: What is the landscape like now with testing and testing tools now?2:39 – Guest: There is a huge renaissance with the JavaScript community. Testing has moved forward in the frontend and backend. Today we have lots of testing tools. We can do frontend testing that wasn’t possible 5 years ago. The major change was React.The guest talks about Node, React, tools, and more!4:17 – Aimee: I advocate for tests and testing. There is a grey area though...how do you treat that? If you have to get something into production, but it’s not THE thing to get into production, does that fall into product or...what?5:02 – Guest: We decided to test everything in the beginning. We actually cam through and did that and since then I don’t think I can use the right code without testing. There are a lot of different situations, though, to consider.The guest gives hypothetical situations that people could face. 6:27 – Aimee.6:32 – Guest: The horror to changing code without tests, I don’t know, I haven’t done that for a while. You write with fear in your heart. Your design is driven by fear, and not what you think is right. In the beginning don’t write those tests, but...7:22 – Aimee: I totally agree and I could go on and on and on.7:42 – Panel: I want to do tests when I know they will create value. I don’t want to do it b/c it’s a mundane thing. Secondly, I find that some times I am in a situation where I cannot write the test b/c I would have to know the business logic is correct. I am in this discovery mode of what is the business logic? I am not just building your app.I guess I just need advice in this area, I guess.8:55 – Guest gives advice to panelist’s question. He mentions how there are two schools of thought.10:20 – Guest: Don’t mock too much.10:54 – Panel: Are unit tests the easiest? I just reach for unit testing b/c it helps me code faster. But 90% of my code is NOT that.11:18 – Guest: Exactly! Most of our test is glue – gluing together a bunch of different stuff! Those are best tested as a medium-sized integration suite.12:39 – Panel: That seems like a lot of work, though! I loathe the database stuff b/c they don’t map cleanly. I hate this database stuff.13:06 – Guest: I agree, but don’t knock the database, but knock the level above the database.13:49 – Guest: Yes, it takes time! Building the script and the testing tools, but when you have it then adding to it is zero time. Once you are in the air it’s smooth sailing.14:17 – Panel: I guess I can see that. I like to do the dumb-way the first time. I am not clear on the transition.14:47 – Guest: Write the code, and then write the tests.The guest gives a hypothetical situation on how/when to test in a certain situation. 16:25 – Panel: Can you talk about that more, please?16:50 – Guest: Don’t have the same unit – do browser and business logic stuff separated. The real business logic stuff needs to be above that level. First principle is separation of concerns.18:04 – Panel talks about dependency interjection and asks a question. 18:27 – Guest: What I am talking about very, very light inter-dependency interjection.19:19 – Panel: You have a main function and you are doing requires in the main function. You are passing the pieces of that into the components that need it.19:44 – Guest: I only do it when it’s necessary; it’s not a religion for me. I do it only for those layers that I know will need to be mocked; like database layers, etc.20:09 – Panel.20:19 – Guest: It’s taken me 80 years to figure out, but I have made plenty of mistakes a long the way. A test should run for 2-5 minutes max for package.20:53 – Panel: What if you have a really messy legacy system? How do you recommend going into that? Do you write tests for things that you think needs to get tested?21:39 – Guest answers the question and mentions Selenium! 24:27 – Panel: I like that approach.24:35 – Chuck: When you say integration test what do you mean?24:44 – Guest: Integration tests aren’t usually talked about. For most people it’s tests that test the database level against the database. For me, the integration tests are taking a set of classes as they are in the application and testing them together w/o the...so they can run in millisecond time.26:54 – Advertisement – Sentry.io 27:52 – Chuck: How much do the tools matter?28:01 – Guest: The revolutions matter. Whether you use Jasmine or Mocha or whatever I don’t think it matters. The tests matter not the tools.28:39 – Aimee: Yes and no. I think some tools are outdated.28:50 – Guest: I got a lot of flack about my blog where I talk about Cypress versus Selenium. I will never use Jasmine. In the end it’s the29:29 – Aimee: I am curious would you be willing to expand on what the Selenium folks were saying about Puppeteer and others may not provide?29:54 – Guest: Cypress was built for frontend developers. They don’t care about cross browser, and they tested in Chrome. Most browsers are typically the same. Selenium was built with the QA mindset – end to end tests that we need to do cross browser.The guest continues with this topic.30:54 – Aimee mentions Cypress. 31:08 – Guest: My guessing is that their priority is not there. I kind of agree with them.31:21 – Aimee: I think they are focusing on mobile more.31:24 – Guest: I think cross browser testing is less of an issue now. There is one area that is important it’s the visual area! It’s important to test visually across these different browsers.32:32 – Guest: Selenium is a Swiss knife – it can do everything.33:32 – Chuck: I am thinking about different topics to talk about. I haven’t used Puppeteer. What’s that about?33:49 – Guest: Puppeteer is much more like Selenium. The reason why it’s great is b/c Puppeteer will always be Google Chrome. 35:42 – Chuck: When should you be running your tests? I like to use some unit tests when I am doing my development but how do you break that down?36:06 – Guest.38:30 – Chuck: You run tests against production?38:45 – Guest: Don’t run tests against production...let me clarify!39:14 – Chuck.39:21 – Guest: When I am talking about integration testing in the backend...40:37 – Chuck asks a question. 40:47 – Guest: I am constantly running between frontend and backend.I didn’t know how to run tests for frontend. I had to invent a new thing and I “invented” the package JS DONG. It’s an implementation of Dong in Node. I found out that I wasn’t the only one and that there were others out there, too.43:14 – Chuck: Nice! You talked in the prep docs that you urged a new frontend developer to not run the app in the browser for 2 months?43:25 – Guest: Yeah, I found out that she was running the application...she said she knew how to write tests. I wanted her to see it my way and it probably was a radical train-of-thought, and that was this...44:40 – Guest: Frontend is so visual.45:12 – Chuck: What are you working on now?45:16 – Guest: I am working with Applitools and I was impressed with what they were doing.The guest goes into further detail.46:08 – Guest: Those screenshots are never the same.48:36 – Panel: It’s...comparing the output to the static site to the...48:50 – Guest: Yes, that static site – if you have 30 pages in your app – most of those are the same. We have this trick where we don’t upload it again and again. Uploading the whole static site is usually very quick. The second thing is we don’t wait for the results. We don’t wait for the whole rendering and we continue with the

Become a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

Avsnitt(725)

Speaking Up: The Developer’s Guide to Conference Talks & Career Growth - JSJ 682

Speaking Up: The Developer’s Guide to Conference Talks & Career Growth - JSJ 682

In this episode of JavaScript Jabber, I am joined by three incredible guests — Ariel Shulman, Liad Yosef, and Evyatar Alush — to dive into the world of public speaking in tech. From the jitters of their first talk to the professional and personal growth that comes with hitting the stage, we unpack the full journey of becoming a tech speaker. Whether you're just curious about getting started or want to sharpen your presentation game, this episode is packed with real talk and insights from experienced voices in the community.We get personal about the why, the how, and the what next of conference speaking — covering the motivations, the process of getting accepted, tips for preparing standout talks, and even how public speaking can open doors to career-changing opportunities. If you've ever wondered what it really takes to be heard on stage, this conversation might just be your launchpad.🔗 Links & ResourcesReact Next ConferenceNo TLB ConferenceJS Heroes RomaniaSessionize - CFP platformReversim Tech ConferenceReact SummitGitNation ConferencesBecome a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

10 Juli 1h 44min

How Holepunch Is Redefining Peer-to-Peer Apps with Bare.js — A New Era for JavaScript Developers -JSJ 681

How Holepunch Is Redefining Peer-to-Peer Apps with Bare.js — A New Era for JavaScript Developers -JSJ 681

In this episode, we sit down with Mathias Madsen, CEO of Holepunch, and take a wild ride through the cutting edge of peer-to-peer JavaScript development. Mathias shares his journey from accidentally discovering JavaScript in college to becoming a prolific contributor with over 1,500 open source modules. His passion? Building decentralized, peer-to-peer systems where JavaScript isn’t just for the browser—it powers the entire stack.We dive deep into how Holepunch is reimagining application distribution with their Pear system —essentially turning peer-to-peer into a first-class citizen for distributing full applications, not just files. No hosting, no servers — just apps shared directly, BitTorrent-style. And because packaging and distributing Node-based apps can be painfully complex, they took things a step further by building a new runtime: Bare.jsBare.js is refreshingly "bare": it strips away the heavy, opinionated APIs bundled into Node or Deno, leaving just the JavaScript core and a powerful module system. What’s revolutionary here is Bare's ability to run the same codebase across desktop, mobile, and even tiny embedded devices—swapping out engines like V8, JavaScriptCore, or JerryScript depending on the platform's needs. This allows Mathias' team to write backend logic once, share it across all platforms, and iterate at lightning speed.Key takeaways:-Peer-to-peer can go far beyond media sharing — it's being used for full app distribution.-Bare.js decouples JavaScript from specific platforms, creating a universal backend that just works anywhere.-Modular design isn't just a philosophy — it's the secret to Holepunch’s rapid development pace.-The combination of React Native for UI and Bare.js for backend creates an insanely productive development pipeline, fully cross-platform.If you’re into JavaScript, peer-to-peer tech, or just love hearing about developers breaking the mold, this one’s for you.About the GuestMathias is the CEO of Holepunch (https://holepunch.to/). He brings his passion for open-source software, and deep experience in the area, having  published more than 1000 modules to npm, the Node.js package manager, totaling billions of downloads every month.Mathias Buus is a self taught Javascript hacker from Copenhagen. He works full time on open source projects and has been working with Node.js since the 0.2 days. Mathias likes to work with P2P and distributed systems and is the author of more than 550 modules on npm, including some of the most popular ones for working with streams. In addition he has spoken about mad science projects at various conferences around the world.Become a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

24 Juni 1h 6min

Migrating a Legacy JavaScript Codebase to TypeScript - JSJ 680

Migrating a Legacy JavaScript Codebase to TypeScript - JSJ 680

In this episode, Dan and I (Steve) dove deep into what turned out to be a surprisingly complex, yet incredibly insightful topic: gradually migrating a massive legacy JavaScript project over to TypeScript. We're talking about nearly 1,000 JS files, 70,000+ lines of code, and years of developer history—all transitioning carefully to a typed, modern future.Dan walked us through how he started by setting up the project for success before converting even one file—getting CI/CD ready, setting up tsconfig.json, sorting out test dependencies, dealing with mock leaks, and even grappling with quirks between VS Code and WebStorm debugging.We talked tools (like TS-ESLint, concurrently, and ts-node), why strict typing actually uncovered real bugs (and made the code better!), and why it’s crucial not to touch any .js files until your TypeScript setup is rock solid.Key Takeaways:Gradual migration is 100% possible—and often better—than ripping the bandaid off.TypeScript can and will catch bugs hiding in your JavaScript. Be prepared!Use VS Code extensions or TS-Node to support your devs’ tooling preferences.Don't underestimate the setup phase—it’s the foundation of long-term success.Start small: Dan's team converted just one file at first to test the whole pipeline.If you’re sitting on a legacy JS project and dreaming of TypeScript, this episode is your blueprint—and your warning sign.Become a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

5 Juni 1h 25min

TypeScript, Security, and Type Juggling with Ariel Shulman & Liran Tal - JSJ 679

TypeScript, Security, and Type Juggling with Ariel Shulman & Liran Tal - JSJ 679

In this episode, we dove headfirst into the swirling waters of TypeScript, its real-world use cases, and where it starts to fall short—especially when it comes to security. Joining us from sunny Tel Aviv (and a slightly cooler Portland), we had the brilliant Ariel Shulman and security advocate Liran Tal bring the heat on everything from type safety to runtime vulnerabilities.We started off with a friendly debate: Has TypeScript really taken over the world? Our verdict? Pretty much. Whether it’s starter projects, enterprise codebases, or AI-generated snippets, TypeScript has become the de facto standard. But as we quickly found out, that doesn’t mean it’s perfect.Key Takeaways:-TypeScript ≠ SecurityWe tend to trust TypeScript a bit too much. It’s a build-time tool, not a runtime enforcer. As Liran pointed out, “TypeScript is not a security tool,” and treating it like one leads to dangerous assumptions.-Type Juggling is Real (and Sneaky)We explored how something as innocent as using as string on request data can open the door to vulnerabilities like HTTP parameter pollution and prototype pollution. Just because your IDE is happy doesn’t mean your runtime is.-Enter Zod – Runtime Type Checking to the Rescue?Zod got some love for bridging the dev-time/runtime gap by validating data on the fly and inferring TypeScript types. But even Zod isn’t foolproof. For example, unless you're using .strict(), extra fields can sneak past your validations, leading to mass assignment bugs.-Common Developer FallaciesWe discussed the misplaced confidence developers have in things like code coverage and TypeScript alone. One of the big takeaways: defense in depth matters. Just like testing, layering your security practices (like using Zod, type guards, and proper sanitization) is key.-TypeScript Best Practices Are EvolvingFrom discriminated unions to avoiding any, from using Maps over plain objects to prevent prototype pollution—TypeScript developers are adapting. And tools like modern Node.js now support type stripping, which makes working with .ts files at runtime a bit easier.Become a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

29 Maj 1h 32min

Building Agentic AI Workflows with Matthew Henage - JSJ 678

Building Agentic AI Workflows with Matthew Henage - JSJ 678

In this episode, we sat down with full-stack developer and AI innovator Matthew Henage, creator of WAOS.ai (Web App Operating System) and the incredible storytelling platform SpeakMagic.ai. This conversation took us deep into the world of agentic AI, low-code app building, and the future of intelligent workflows.We kicked things off with Matthew sharing how he’s been riding the AI wave since GPT-3.5 blew his mind. His platform WoWs is all about making it easy for developers to build powerful web apps with embedded AI workflows — think of it like Zapier meets ChatGPT, but with agents working together instead of API chains.One of the most eye-opening parts of our chat was learning about agent swarms — essentially teams of specialized AI agents that collaborate to perform complex tasks. Instead of relying on one giant AI brain to do everything, you create smaller, purpose-built AIs that handle specific steps in a workflow. It’s scalable, smarter, and kind of like assembling your dream dev team… but all made of code.Matthew’s Speak Magic project is a jaw-dropper. It uses a swarm of over 40 agents to turn a single story idea into a fully animated, two-minute video — complete with scenes, scripts, character animations, music, and more. It’s AI storytelling on steroids.We also talked a lot about:Best practices for building reliable AI workflowsThe importance of keeping context windows small (under 4,000 tokens works best!)How prompt engineering is becoming the new programmingUsing AI for vibe coding (yes, that’s a thing) and rapid prototypingThe tradeoffs between using traditional programming vs. letting AI handle logicEthical considerations and how to handle memory and privacy in long-running user interactionsCheck out Matthew’s work at WAOS.ai and speakmagic.ai — and as always, stay curious and keep building!Become a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

22 Maj 1h 3min

Reinventing Web Development with Brisa: A Conversation with Aral Roca - JSJ 677

Reinventing Web Development with Brisa: A Conversation with Aral Roca - JSJ 677

In this week’s episode, it’s just me — Charles Max Wood — and I’m joined by the incredibly sharp and open-source-loving Aral Roca, direct from Barcelona! Aral’s the creator of Brisa, a new full-stack web framework that flips the script on how we build modern web apps. If you thought the "another day, another framework" meme was played out... well, Brisa might just change your mind.Key Takeaways:-Brisa’s Big Idea: It's designed to let you build web apps with minimal or zero JavaScript on the client side. Think HTML streaming, server actions, and components that render server-side first, but can gradually hydrate on the client.-Server-first FTW: Aral walks us through how Brisa handles server actions — even capturing click and scroll events on the server — using ideas inspired by HTMX, LiveView, and server components from frameworks like Next.js.-Tiny and Mighty: The whole framework is incredibly lightweight. Web components come in at just ~3 KB, and the built-in i18n system is under 1 KB!-From Idea to Reality: Aral started Brisa to scratch his own itch — building side projects and blogs without bloated front-end code. But now, others are using it too (yes, even in production!), including one travel agency that's gone all-in.-Multi-platform Future: Brisa has adapters in the works for Vercel, Node, and Deno — plus integration with Tauri for building native Android, iOS, and desktop apps from the same codebase.-What's Coming: Roadmap goals include improved hot reloads, more adapters, transitions, lazy-loaded components, and a better playground for developers to tinker with.Oh, and yes — Aral does parkour. For real.This episode is packed with deep technical insight and exciting potential for a new way to build web apps — especially for devs who love fast performance, server-rendering, and clean architecture.Become a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

15 Maj 1h 5min

Building Enterprise Infrastructure with Bit & AI with Gilad Shoham - JSJ 676

Building Enterprise Infrastructure with Bit & AI with Gilad Shoham - JSJ 676

In this episode, I (Steve Edwards) flew solo on the mic but had the pleasure of hosting a truly insightful conversation with Gilad Shoham, VP of Engineering at Bit.Cloud. Gilad brought the heat from Israel as we explored how Bit is revolutionizing enterprise software architecture—and how AI is being layered on top to supercharge developer productivity.We started by breaking down Bit’s core platform, which helps teams compose applications from reusable, independently versioned components. Think Lego blocks, but for your codebase. It’s all about boosting dev velocity, reducing duplication, and making collaboration across teams more seamless.Gilad walked us through some jaw-dropping features: versioning without Git, deep component CI pipelines, and even Bit’s ability to replace monolithic repositories with a graph of decoupled components. Everything is Node + TypeScript under the hood, and while it’s currently JS-focused, the ambition is clearly broader.Then came the big twist: AI. Bit is now leveraging AI not to just write code, but to compose it using existing components. Instead of bloating your codebase with endless variations of the same button, Bit’s AI understands your graph and builds features by intelligently reusing what’s already there. It’s like Copilot with a memory—and architectural sense.Key takeaways:Bit components wrap your existing code (like React/Vue) with metadata, testing, and versioning.Their infrastructure makes it possible to build and test components independently and in parallel.The AI strategy is reuse-first: generate only when needed, always compose from what already exists.Even massive enterprise codebases can gradually migrate to Bit without a full rewrite.Expect a human-in-the-loop process, but with most of the heavy lifting handled by AI.Become a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

8 Maj 58min

Replacing Create React App: Why Create TS Router App Is the Future of React Development - JSJ 675

Replacing Create React App: Why Create TS Router App Is the Future of React Development - JSJ 675

We’ve been diving into the evolving landscape of React app development and why tools like Create TS Router App (CTA) are stepping up to fill the gap left by the deprecation of Create React App (CRA). What we’ve learned is that SSR (server-side rendering) isn’t one-size-fits-all—e-commerce sites need it for SEO and performance, but internal tools and dashboards often don’t. That’s where CTA shines. It gives us a fast, modern, Vite-powered setup with TanStack Router built in, so we can start small and scale up without committing to heavy frameworks like Next.js from day one.What we love about CTA is how it keeps things familiar (same structure as CRA) while giving us type safety, file-based routing, and the flexibility to add only the features we need—like Clerk, Sentry, or even SolidJS support. Whether we’re building a simple prototype or a full-featured app, CTA makes the experience smoother, more intuitive, and future-friendly.Become a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

2 Maj 1h 30min

Populärt inom Business & ekonomi

framgangspodden
varvet
badfluence
svd-ledarredaktionen
rss-borsens-finest
uppgang-och-fall
lastbilspodden
avanzapodden
rss-dagen-med-di
affarsvarlden
borsmorgon
fill-or-kill
rss-kort-lang-analyspodden-fran-di
rikatillsammans-om-privatekonomi-rikedom-i-livet
tabberaset
dynastin
kapitalet-en-podd-om-ekonomi
montrosepodden
market-makers
rss-inga-dumma-fragor-om-pengar