The Elixir Outlaws now have a Patreon. If you’re enjoying the show then please consider throwing a few bucks our way to help us pay for the costs for the show.
Episode Transcript
Welcome to Elixir Outlaws, the hallway track of the Elixir community.
Amos: Are you sure you don't just don't have a really laggy connection?
Chris: I am wired into the gig, my friend, the gig.
Amos: Me too. I have no idea, then.
Chris: Yeah, but my gig is awesome. And yours is, uh, probably provided by the people that I ostensibly work for.
Amos: Google.
Chris: Uh, Oh, you use goo. Oh, you're in Kansas.
Amos: City.
Chris: You got that Google.
Amos: In Missouri. (whispers) I'm in Missouri. I know the president thinks that the Chiefs are in Kansas. Ex- president. Ex-president.
Chris: Are we even in, are we even in Kansas? I went to a, I went to a show in, uh, Kansas City at one point and the band was like, "Are we, are we even in Kansas right now.? It's called Kansas City. But we're in Missouri. What happened? How did, how did you manage to, did you lose the city?" Like, it was a lot of like, he was genuinely confused.
Amos: He wasn't just trying to be funny.
Chris: I think he, it might've been a very British humor style of humor, but, uh, yeah, no, he, he was, I think, uh, it was three parts humor, seven parts legitimately like, how does, how did you manage this? How did this happen? Who's responsible? You know what, let me speak to your manager. I feel like we need to sort some of this out.
Amos: Did it work? Did you speak to the manager?
Chris: No, no, no, no.
Amos: That's too bad.
Chris: Absolutely not. No. I don't want to be involved in any decisions whatsoever.
Amos: Especially with a English band.
Chris: Yeah, absolutely. I don't know what that means, but sure.
Amos: There'll be the wrong number of M&Ms in the green room.
Chris: Oh, right. Yeah. I don't, I still don't understand this reference, but yes.
Amos: Holy cow, did I make a reference that you didn't get. That's a first.
Chris: It it a spinal tap reference?
Amos: No. Well, but it could be, uh, it could be, um, there are some English bands. Well, there are bands in general who are famous for having weird demands in their green rooms and then exploding whenever they aren't met.
Chris: I thought that was just called bands.
Amos: Yeah. That's probably is.
Chris: Yeah, I don't. I feel like that's just bands. Uh, but good joke though. Anyway, so what's been going on?
Amos: Thanks. Um, not much I've been, uh, pretty busy, started on a new project on Monday. And so that's been pretty cool. Rolling along. It's a Phoenix project, which is different for me. Uh, cause you know, I've, I've done a lot of the backend just server work and embedded systems stuff, but have not done a whole lot of Phoenix. So doing that full time is, is fun. Kind of back to my web roots a little bit.
Chris: Are you living the LiveView life or the dead view life?
Amos: Uh, right now all the views are dead view, but there's probably gonna be some LiveView in there. Uh.
Chris: How are you going to be modern, though?
Amos: Well, we are not going to offer offline support, that's for sure.
Chris: You're going to migrate the same such LiveView. The View.
Amos: We will have at least some of the pages being LiveView, I don't know that we're going to do all of them that way. Uh, I did recently add some LiveView to our internal invoicing software. Um, and that was fun. It's hard though, in my brain still to, to, um, go from that when I'm looking at a website to think in that back and forth constant communication. Instead, I still think in that request cycle, just because I'm looking at a browser, so that's, that's a little bit tough for me. It's like, “Oh yeah, we just need to add more to the change set.” One thing that frustrates me though, is when you have lists of things that you want to add, and if you want to add them one at a time, you can't just keep putting them in the change set cause they overwrite, like if you add one more, it just overwrites the change.
Chris: Aah, sure.
Amos: So you have to like pull the data out of the change set and append it and then put it back in, to change that over and over and that's kind of obnoxious. But other than that, it's been, it's been pretty cool.
Chris: That's cool.
Amos: It did cause us to change a lot of the workflow in the front end, but we got good feedback from Carolyn who does our invoicing. She really liked the flow of it and said it actually works a whole lot smoother now.
Chris: To, to like being, um, having that sort of like instant rendering kind of capability.
Amos: Yeah. And instant error messages. Um, so like if you, if you type in a letter on accident in the, um, in a, an invoice, uh, which we could have done with JavaScript before, you know, we just, we just weren't. Um, but now like when you add a line item to an invoice, it checks it immediately instead of waiting until you try to add all of them, um, or we have a, we have a way to add discounts, but discounts have, discounts can only be applied once. And that could get weird before it still can. It can get to some weird situations, but you get more immediate feedback whenever you try to apply a discount, it actually goes to the back end and tries to apply it. And if it can't, it'll immediately tell you, instead of before, it would wait for you to submit the form. So you might apply a discount, add three line items and submit. So even if we had fixed the line-item thing, then we would have to do a back and forth to check the discounts anyway.
Chris: Right, right, right.
Amos: So that, that is got a pretty nice workflow now.
Chris: Nice.
Amos: Also start- ope, go ahead.
Chris: No, no. Please carry on.
Amos: I was just going to say, we also started looking into utilizing, um, like the Tailwind stuff. I'm a little bit, I'm a very semantic markup person. So.
Chris: You grew up in the Zen garden.
Amos: Right. So it's like a, this feels really dirty, but if we can figure out components, I think that it would be fine.
Chris: Yeah. I think all of it is crap. I think all of it's garbage. I think all of it is such a bad it's so, also bad, but I mean, it's also bad. And so it kind of just like all those rules, all the ID ideology about like semantic markup or not, or whatever, some of it has merit. I think the stuff around, um, accessibility matters a lot. But beyond that, I don't think any, I don't, I don't think any of that,
Amos: The inline styles-
Chris: So like put your stuff, put your stuff wherever, like literally put your stuff wherever, do it however you want, because it doesn't matter. It'll be different next month and it's all crap.
Amos: Oh, I agree that it will be different. My big thing about the like in line style stuff is maintenance. If you're always putting it in style, if you're not reusing portions like doing components or, or anything like that, you ha if you're doing in line styles and you're doing buttons everywhere, that becomes a maintenance nightmare. If you, get a redesign.
Chris: Yeah. It, it feels like a workflow that is designed for React or View or one of those things, you know what I mean? It feels like a workflow that is like the, you know, uh, everything is important in context is the CSS, Zen garden mattered when no one freaking understood CSS. And it matters less now because still no one understands CSS, but you can get away with understanding it with like, you can get away with a lot more now.
Amos: Yeah.
Chris: Like here's the thing about CSS. CSS is crap. CSS is garbage. Um, it is actually atrocious and there is no rhyme or reason to why it works the way it works, the way it works. And we just have to, you, you just have to memorize it.
Amos: What do you mean, the way it works? Like what part of it it?
Chris: It's the periodic table. Like, but with, with less scientific backing, you just have to memorize all of it.
Amos: (In the background) Hydrogen, helium, lithium, beryllium, boron, carbon, nitrogen, oxygen.
Chris: Yeah. You just need to memorize this, you know, it's I, before E except after C and sometimes occasionally, Y like,
Amos: Well but not every time, because sometimes E has to come before that, right.
Chris: Yeah. You know, and it's like, it's just a goulash of nonsense. Um, and I, yeah, I think it's, it's so much like you just need to memorize the ways that this works and why it works that way. And here's like these 10 tricks that allow you to, to achieve the thing that you're actually trying to achieve. Um, and so much of what people do, like there are people who are really good at CSS and it's because they just have all that stuff in their head. And the rest of us just like go into the inspector and add tags and twiddle stuff until it does what you mostly want it to do. And then you refresh the page and see if it's sticks, like-
Amos: I do feel like, like CSS when I'm, when I'm playing with CSS, playing I- playing is probably not the right term, banging my head against the monitor to do CSS, I feel like I'm, I'm in a boxing match. And, and I gotta, I gotta trick CSS into doing what I want it to do.
Chris: Yeah. I think that's, that's, that is the experience for most people. Um, and that's why, and so it's like, that's kind of why I'm like, it doesn't matter, like, you know, just in line styles, whatever, like it's all bad, you know, it's all hacks. To get around the fact that the underlying thing is super broken.
Amos: I don't feel like there's been any real advancement in CSS stuff.
Chris I actually, since I think it’s-
Amos: I think its SAS actually, like being able to add functions and things like that in which SAS brought to CSS was like, that's the biggest advancement.
Chris: And if you really want to get down to it, the biggest advancement to CSS as a language, not as, not as capabilities, right. Cause like Flexbox doesn't count. You know what I mean? CSS grid does not count in terms of like making CSS better.
Amos: Yep.
Chris: That's just adding features, right? It's like the pattern matching doesn't make JavaScript a better language because the fundamentals underpinning it are, you know, are, are not there. And so all that trappings, like all the trappings of, you know, adding grids and Flexbox and all that sort of stuff, those are all nice. They don't fix the fundamental problem. And the fundamental problem I actually think is a mathematical one. Like I actually think CSS will never be better.
Amos: Why's that?
Chris: CSS, as you know, CSS is declarative, and it works at a level of computational power above what you actually need. So you actually can't improve CSS because it's declarative.
Amos: Say more, say more.
Chris: Okay.
Amos: You've got me thinking.
Chris: Yeah. I, I see you, uh, through the, through the power of the internet, I see you thinking your rebuttal, sir. Yeah. You're sorry, your time's up.
Amos: Yeah, I'm ju- I'm just, I'm trying to picture the declarative nature, holding it back because in my head I was going completely somewhere else. And part of it was that it's procedural nature that it, it, you know, like, just as an example is, uh, just the other day I was reminded that like a sibling selector can only get a sibling that's after the current one, cause it's always goes in, in, down the document, which I think sometimes causes people instead of doing what they want, they change the HTML in the document in order to make it fit their CSS that they want to do. Um, which kind of, I guess in a way, bothers me a little bit, cause uh, you know, HTML is supposed to be for structuring a document and when you have a structure and an organization, and then it makes you add in extra divs and things just to, to be able to make things look the way you want it feels wrong.
Chris: Right. So the, the, the problem that I see is that, uh, CSS is your only vehicle for painting in the browser, uh, setting aside. Yeah. I mean, setting aside the, well, actually folks who are going to be like, Oh, there's Canvas and there's SPG. And like, yeah, no, it's like, that's, that's not what I mean. Right. But like, if you want to manipulate Dom elements as elements, um, the only way to do that is CSS, like if you want to affect the painting rules of the browser, the only way to do that is via CSS.
Amos: Right. Even the JavaScript things, right?
Chris: For DOM elements, right.
Amos: Even the JavaScript things change the CSS and the DOM element to move things around.
Chris: Yeah. And you can change like sizes and stuff, but those are, that's all CSS elements at some, you know, at some level. So, uh, the problem with that, uh, and the fact that it's declarative is that it means that, um, the only thing that you can do is output CSS. The only way to improve CSS is to build a thing on top of it, that outputs CSS, right? Like there's no like the, the fundamental problem is you don't have access to the actual procedural imperative drawing and painting rules in the browser. And if you had access to those, you could build an actual alternative to CSS. Like if that was the API, right. If all browsers had a fundamental API that was like, draw this in these pixels, um, then you would have ability to do that. And they do have that it's called Canvas, which is , we're going to set that aside for a second. But like, if you had access to sort of more fundamental primitives that actually did drawing and painting will, like, at that point, you have more computational power and you're not beholden to the browser's interpretation of the CSS rule. And so, because CSS is this declarative thing, it actually works at like sort of a less, uh, computationally, powerful level, like Chomsky hierarchy kind of like level. Uh, and this is all me just like, you know, this is like three IPA's in thinking, right? Like this is, this is borderline like stone theory.
Amos: I didn't know we were bringing drinks this morning; I would have been on it.
Chris: You would have been, I'm saying, like, this is, this is up there with like my, you know, this is, this is in, in the kind of almost like weird conspiracy theory land. Like, you know, uh, this is, this is borderline, "What is money, even, man?" that's, you know, like levels of thinking. But I think that's the problem. I think the fact is like, you have, you only can use CSS. CSS is your only vehicle to do anything. And so because of that, uh, it's deeply limiting and it's why no one has fixed it. Right. It's why like all this crap that is that, you know, all this cruft and all this, this, this kind of weird box model thing and Flexbox and all that stuff, why all these extensions are alternatives. Like don't fix the underlying thing because you don't actually have access to fix the underlying thing. And more power to the browser people and CSS people for keeping all that stuff backwards in combat or backwards compatible. That's a huge boon to the internet. The fact that HTML and CSS is backwards compatible is this massive, massive boon and is really, really important. And you, and like I say, you could have a thing though, that just outputs, like, here's what I actually want you to do. We just don't have that. And because of that, all we have a CSS and I, I really do think that that's the main, that's why you get post processors that just output CSS and, you know, are very limited in what they're actually capable of doing. That's why, like, you can't substantively fix that stuff.
Amos: It's hard, hard to innovate when you have a minimal set-
Chris: Yeah, you're handcuffed, you're handcuffed into the thing. And that's why the ways that people interact with CSS these days, right? Uh, like I think, you know, it's like, it's like one of the, one of the most important things to happen in CSS is like Bootstrap. And people like don't like Bootstrap, but Bootstrap is super important part of CSS's history and, and things like that, right, Foundation and all that sort of stuff, is a super important part of CSS history, because it gave people names and like, like semantically useful names for all this stuff. And like, and did a bunch work to like, it's the closest thing you have to like a solid improvement on the way that people interact with CSS. People don't say people don't like it, but it's like, you know.
Amos: They gave it every, like, so before that, every time I, I had to do a web project, you know, you had your set of styles that you copied in because every browser was going to have default styles that were different. So you had to override everything. And so they gave like, I guess through pushing that, like I had my own set, right. That I com that I put in, but Bootstrap gave everybody that same set or at least to a much wider audience than then the one that I had that I passed around to 10 friends, right. So by giving everybody this common starting point, I think it actually allowed more learning about CSS and, and pushing it further because that starting point wasn't so painful because you didn't spend all of your time trying to make it look the same in every single browser.
Chris: I think it made people realize too that like we needed better primitives. And so like, Flexbox is a better primitive for building stuff. I think that, but, but it's all, but it's only ever going to be extensions. You know what I mean? No one's ever going to build a better language. That's the, like cause they can't. You can't build a better language than CSS because CSS is the, is the only thing you have access to.
Amos: Would you get every browser manufacturer to throw in a new language?
Chris: Absolutely. I don't think you would like, this is, this is again, like, you know, borderline "What is money?" Uh, like, yeah, it doesn't matter. None of this matters, like this is just my, there's, all this, all this to say, it's all crap. Like it's all it's, it's not going to be fixed, so you just live in the world that you live in and you figure out what you need to do to make your team the most productive. Like, what does your team want to maintain? Does your team want a bunch of like components that have common styles that they can, you know, tweak via React, like properties that you pass down? Go for. It seems good. It seems good. And I don't know how you do it with a Le-View, but, uh,
Amos: (laughs) It took me a minute.
Chris: Because I haven't tried it. It took me all day to get a modal working. Um, I am not a Le-View expert, although I guess I should be, if I ever want to give another talk at an ElixirConf.
Amos: Nice. Uh, I mean, it's, I haven't, I haven't had any, anything different in, in LiveView versus, um, just the traditional templates. I mean, it's, you're, you're putting out the same HTML, but I guess, I guess the event tags that you put on, there are a little different, like you're not putting, you're not putting, you're not attaching JavaScript and yourself. And so you've got directives kind of like, kind of like you would with React or anything. One thing that I did find, uh, yesterday or day before that I thought was really interesting though, is for components. So you could make like your own tags, kind of, in your HTML. And I really like it's called Surface and I thought, “This is awesome-
Chris: I've heard of this.
Amos: -I want to use it.” And then it only works in LiveView. They say that you can use it in templates, but to tell you the truth, I spent so much time trying to figure out how to do it. And then it really seems like you, well, what, how I found out I could do it is to wrap it in a function and then call that function like a templated function. And that didn't allow me to add a new tag, but I really want to add a new tag because then my D my front-end guy, all of his tools and his autocomplete and everything still work, because once you do the percent or percent equals, none of his auto-complete works as far as, like, if you want to add a CSS class, he's got autocomplete that knows all the classes and that quits working. So I'm trying to give him tools to allow him to move faster. And I was, I was a little sad. Um, but I hear Mitch has one.
Chris: Mitch's Temple, friend of the show.
Amos: Temple. Yep. Yep. I haven't a,
Chris: Temple is not a friend of the show, Mitch is a friend of the show.
Amos: Mitch is a friend of the show. I haven't dug into it much. I already have, uh, you know, your project. Well, it was your project. Now Mitch's project, Wallaby, in our starter stack because all of the other testing, you know, you, you like fake out the form and send it in, which is great, but like I've already written the form. And now I don't know if my form is right. I could have a type of my form and everything is still broken. Now I do stick it to like happy path for the most part. So, so I appreciate having Wallaby at my starter stack.
Chris: Man. That is a project, aww man that is a real, I used it the other day for a thing actually for the first time in a long time. It's one of the reasons I like kind of passed ownership of that project over is cause I wasn't using it all that often. Boy, there's so much I would do different.
Amos: Enlighten me. What would you do different?
Chris: Well, there are so many things. Oh, just API design. My sensibilities about API design have changed so much, so much. It's really wild. Actually.
Amos: Do you have any specifics in your head that you know of?
Chris: I think one of them is just like, you don't want that many modules. It's like, like you don't actually want that many modules in your, uh, in your APIs that for users to consume and the ones that you do have, you want to hide them all. Like, it's, it's always really funny to me when I look at a lot of libraries that are out there in the world and, uh, look at libraries and, and like they have every module that's in the app, just in the docs.
Amos: Yep.
Chris: So they don't hide all that stuff. And then you have to like kind of puzzle through and figure out which of these am I actually supposed to use, versus which of these are like internal only. I really tried to have like a module.
Amos: I, I appreciate that. Like, that's one of the things in Wallaby right now that sometimes it's like, Oh, crap, is that on browser? Or is that on query?
Chris: Oh, that's bad. The entire way you interact with it's bad too, I think. Um, and I, and I've had a lot of thoughts about how I would fix that, but at this point it's like, I don't know that I would actually spend the time to go do it just with all the other libraries I have out there in the world that need to be fixed and worked on.
Amos: I do like that everything takes a session and returns the session, unless it's, unless it's a Boolean, except for some of the Booleans they return true or throw an exception right now. I got frustrated with Mitch the other day. Sorry, Mitch.
Chris: A lot of, yeah. I mean, there's a lot of, I mean, a lot of us just like, “Chris didn't know what he was doing,” you know what I mean? Like that was so much of a learning project where I was just trying to like figure it out and I didn't have a, a design sense for it and looking back on it, I like, because I looked at the code the other day and I was like, “Oh, wow.” Yeah. Like I had no clue what I was doing. So it was all bad.
Amos: So I never use any of it directly in my test. I ha I wrap pages in modules so that I'm not finding all these elements and stuff. And I think that is.
Chris: Totally reasonable. That's that is the right way to do it. I would say,
Amos: Well, and I, and I, I dunno, maybe I should go add some stuff. I feel like I should now make a PR to the docs just to show that because the docs are all based on like putting it there, you know, it's that, that trying to get, show you a quick example thing. It's not necessarily the, the right way to do it. It's saying here's how you get started. But adding something into the docs about that, I think would be good, now that we're talking about it, I feel like I have to go do it today.
Chris: Yeah. I mean, I think it's one of those things that I, yeah. I don't know. I, people undervalue the maintainability of tests. Like people don't treat tests like real code. Not in my experience.
Amos: That depresses me.
Chris: You know what I mean, though? Like, I'm sure you've seen that. Right? Like people don't act like test code is real code that you needs to be, you know, tended and rethought and redesigned. Like, I don't know you should be deleting tests, like a lot of the time, like consolidating them and like working through like, is this even relevant anymore? Do I need this anymore? Does this do anything for me?
Amos: I liked that. I liked that idea of, of deleting tests every so often.
Chris: I like the idea generally, cause they slow me down. All they ever do is like make, block CI, and like keep me from deploying. I just want to deploy code.
Amos: Well, when it fails, I think that's a time that you should stop and say, is this test worth fixing?
Chris: No, I should never be forced to stop ever.
Amos: Well.
Chris: I just want to type, I want to, I want to feed my key presses directly into the.
Amos: Well, if you didn't screw up-
Chris: I never screw up. See, that's my secret. It's never my fault. It's always someone else's, clearly.
Amos: If your test failed for the wrong reason, you have a brittle test framework and you need to figure out how to make a better test.
Chris: Absolutely. But if my, if the test fail, because I wrote the code badly, that's on the test as well. I would say. The test should have predicted that and accommodated me.
Amos: Fair.
Chris: Absolutely. So, no, I, I, um, yeah, I don't think, I think people do not value, uh, yeah, the test maintainability thing. And I think the page, the page modules idea is super useful. Man, ike as a, just have like, as a general thing, all of the testing stuff that Skip's using, like the real server, man, I ain't about that life. That noise is not that noise. I am not about that life.
Amos: If I still like unit tests. Uh, but.
Chris: No, unit tests are fine. But I just mean like all the things that like pretend to be hitting your actual server, but then don't and like just call the functions directly and like skip a bunch of stuff. All useless. All, all of them are useless.
Amos: So I feel that way about like the Phoenix controller testing.
Chris: (Shouting) YES! That stuff bothers me so much!
Amos: And like, conn tests, I'm like, I'm like, wait, I'm like, again, I made the form on the front end and now I have to make the form again inside my test. Like why I, it, it frustrates the crap out.
Chris: Just, I, uh, like I am really close, for, cause I mean, I dunno, I deal with, I deal in services. You know what I mean? I don't, I don't build UIs that often. I man, I, um, have like, I think my ideal test, we it's curl at this point, it’s like bash and curl and JQ. That's like.
Amos: That's not terrible, right?
Chris: I'll take that. Because then here's the thing. Here's the, let me, I'm going to break it down for you like a fraction. Here's the thing. Once you have that test suite, right? Once you have the test suite that tests, just like the outer layers of the thing. Oh man. The world's your oyster. You can do anything. If you can fully like, it's so easy to go into your code in your tests, especially cause it's like in an Elixir, right. It's so easy. Even if you're making real HTTP calls, which we have like helpers essentially that make real HTTP calls and make it look all clean and stuff. And that does that in Elixir, but it's just too easy to be like, and I shoved this into the database. So it just magically starts there, right? Like that's, you know, assuming that given the databases in this state, when I make this call, it does these things and the way you do it is like, you just like hit the database directly and shove some stuff into there or whatever. Uh, that is the worst. That stuff is the worst. It's the worst.
Amos: I get that. I do it sometimes, though.
Chris: It's so convenient. It's so convenient. And you just do it because it's so convenient and so easy. And often like the APIs don't, that you're providing, don't have everything you need because there's also this background process thing that needs to run. And then your test suite is going to take a billion years. You know, it's like, you know, it's just too, too difficult to do at all.
Amos: So like I do it, but you know, so I might have a test with, let's say Wallaby, that does a, a registration, right? So that's going to create a user. In the backend, I try to wrap as much of that into a single call as I can. And then in the test, you know, I have the test for registration. That's fine. But when I go to do a test for something else and I need a registered user, I don't want it to run the front end. It takes forever. So I try to go through that one call in the back, try to minimize what I'm actually building up in my tests. So that, so that if the database changes, hopefully I don't have to change much. Or, or if anything, um, cause that's what I've run into is like doing fixtures and your fixtures are calling into repo directly and doing, like just injecting data at that level. Then it's like, well, you bypassed everything that you built in the app. And when you change one thing, you're, you're going to be out. I've even run into a lot of test suites that bypass validations in their fixtures to just jam stuff directly. And I'm like, “Whoa.”
Chris: Yeah. But like, that's my thing is like the value add of testing every like testing the service as a black box. Oh man. Like I get that it's slow. I get that, you know, all that stuff. But like here's my problem with it though. It's like, that is, that's actually the only contract that matters.
Amos: Yeah. That outside contract.
Chris: The outside con the contract you're giving to the outside world is the contract. That is the contract. That's the only one that, that freaking matters. And so you want that like, okay, so, so let's, let's say that like, yeah, you don't get your data via, you know, an HTTP call, you get it via Kafka pipeline thing or whatever. Like, you know, like-
Amos: Oh yeah, I saw your Twitter this morning. Why you bring it up.
Chris: Oh, you know, Rabbit, whatever. You got it through some backend queue, you got it through some other means, right? That's like hard, you got to you cause you're opening a UDP socket somewhere. And then, you know, like somebody shoving like telemetry to you or something like that, right. Whatever it is, you have some other means of getting the at that that data gets there. And it's not just HTTP calls, right. Well, there's so much value in like a test that amounts to a bash script. You know what I mean? That just like net cats, you some packets and then hits and then hits your, uh, your, your API and like a tight loop until it resolves or not. Like there are so like that test just tested it, like so much of your application and it didn't, it only coupled you to the thing that matters, which is your contract. It didn't couple, you, it didn't couple your entire, it didn't handcuff you into a crap design.
Amos: Right.
Chris: Because it's only attaching to the thing that matters, which is the thing that the outside world sees. And like, there are, you know, I'm being more bombastic than I actually feel about this stuff. Like there are definitely parts of your system, like I do property-based testing, man. Like I get it. Like, there are parts of your, there are units in your code that are worth doing that on. And, and like getting down deeper into those layers of then testing them to make sure they actually do all the right validation. That's super useful too. I get that, right. But you don't want that many of them, you don't want that many tests. And like, because all that stuff's coupling and it all keeps you from iterating on the design. Like, like out of, you hit some inflection point, right? Like there is some magic Goldilocks number of tests that you need to validate a thing. And if it's like, you know, pure functions, it's like probably one property-based test or two property-based tests.
Amos: Right.
Chris: Which are, you know, reasonable to change or delete. If you've got like 10 function, 10 tests to like, you know, do 10 different types of validation, like you're probably, that implies to me that you're missing a whole bunch of stuff. Cause it takes 10 things to do it. Which probably, if it takes 10 tests test something, that's probably not enough. You probably just wrote the amount that you, you probably wrote the amount that like you were, you had time to run.
Amos: You had test fatigue.
Chris: Yeah, yeah, yeah. You just stopped writing tests at some point, right? No, so like, there's that aspect of it, but you do have to val- you want to validate that stuff, but there is a Goldilocks zone where you want the exact amount of tests and not anymore, not too hot, not too cold, like not too many tests, not too few. And if you go into the too many tests thing, that's, I am going to go out on a limb and say, that's worse in a lot of ways than too few.
Amos: So I could see that. I think that if you can, can figure, I think if you can figure out property testing at that level. And I'm really, I think once you have that page object idea, like if you're doing a website and you can really treat it like a black box and do property testing and generate commands that run your website and run that on like a Saturday when nobody's around, just let it run all day long and you can get some fantastic confidence in your test suite and in your software. So like combining Wallaby with prop check is, is the beautiful thing, in my opinion, if you're going to be doing a web based or even if it's a curl based, right. If you can generate some curl commands or whatever, I think if you can black box property test your system, that's pretty, you're, you're, you're on your way. And then you don't even do example tests anymore. Just throw them out.
Chris: Yeah. Yeah.
Amos: Use those to figure out what properties you want and then throw 'em out.
Chris: I mean some of that stuff is so complicated that the property-based test just doesn't it's like so deeply complicated and time-consuming to write and contain. Like I've had some of those stateful tests that are just massive and sometimes you're, they're warranted and sometimes they are super not. And I've definitely been guilty of doing it where it probably didn't warrant it and then no one could understand it. It was like, the test file was like 500 lines of code and it, and it made no freaking sense to anybody who wasn't me. So, so there's that aspect of it too. You can't just introduce that stuff, but like if you have it where it matters and if you document it well and you, and you write it well, it can be really, really, really useful. And then yeah, like you have the example-based stuff at the, at the outside or, or, or a big property-based test. If your service is simple enough, um, it has reasonable liveliness guarantees for that and is, and is deterministic enough. That's the other problem, right? Is most services aren't, uh, deterministic enough to do that with, cause they're, they're fairly ad hoc-ly specified. Ad hoc-ly is not a word, but you get what I'm saying? Like, like, yeah, like there's the specification is so ad hoc.
Amos: It is now. Hey, hey, if Shakespeare made up words, you can make up words.
Chris: Yeah. That I really feel like I'm probably in the same sort of camp as Shakespeare in terms of being a wordsmith, so.
Amos: Absolutely.
Chris: Worth it. Um, in any case we gotta be kind of leery, like stateless testing, property-based testing is actually pretty reasonable, and most people will get it when you, when they look at it and it's not too bad. I had to do that the other day. I actually did that the other day for a thing.
Amos: So at some point we should talk about how to, how to organize state-based property-based testing, stateful properties tests, because I think there are some, some really good things in there, like you said about documenting, but I think there are some other good things that can go into creating those. Maybe we can get, uh, get our good friend, a friend back on.
Chris: Did you literally forget his name?
Amos: I just totally blanked out. I just wanted to-
Chris: Wow.
Amos: I just, I just wanted to say his handle instead, because...sorry, sorry, Fred. I could have said Ferd and looked like I have no idea who he is.
Chris: No. Yeah. So I think, um, you know, I mean, it's used in the correct places it's really useful. And, and obviously like, all this stuff matters, right? Like stuff around your data and data manipulation matters. If you're, you know, building, uh, if you're, you know, if you've got seeing single global processes everywhere, um, and you're using a lot of gen servers, man, like you're in a bad time, you're going to need to spend more time around that data and make sure you're not, you know, like your example based tests are probably not cutting it for, for ensuring that you're not getting into bad states. You know, bad data is like the, is actually the worst technical problem that you can get in your, get yourself into, like poisoning your own data is easily the most expensive, most costly problem.
Amos: Sometimes you can't fix it. Like you have no idea what the data should be. You're like, “Yeah, I don't know. Can't help you.”
Chris: Yeah. Like you can get in really bad states, if you aren't careful about how you're manipulating data, that's the stuff that you care about. But yeah, but I don't know, like I just, I can't get on the train of like choosing speed, test speed, over validation. I will never sacrifice, uh, I will never sacrifice like more validation on the altar of test speed.
Amos: Wait, are you saying if your tests are slow, you, you will throw them away before validating?
Chris: No. I'm saying, I'm saying if my tests are slow, but do more validation, I will always choose that over fast tests that do less.
Amos: Oh, okay. Fair, fair. Yep.
Chris: And I think that's the, that's the controller test thing for me, is like, I don't actually care at all about like, I want, I want it to go through the stack. Because there's been times like I've actually like shipped production bugs because that those tests didn't catch stuff. Because they, they only call a limited set of things. They don't really validate the stuff that's going in and out. And I've totally shipped like production bugs because that like, a service didn't have a real API test.
Amos: And the controller tests and the front end API tests are like minuscule-y testing, like minuscule-y different, right, in, in their purpose. You're just adding an extra layer. Like if you're supposed to pass in three different arguments, you're still going to do that from the, from the front end test that you were going to do in your controller test anyway. So you might as well add that extra layer. The test doesn't get harder to write. And sometimes it gets easier to write.
Chris: Yeah. I mean, the, the downside is you don't get the plug con, you don't get all that other stuff, right. You gotta, like, you don't have any of the helpers for it and you don't have a nice API for it, which is again, why like most of our services have that stuff built into it. Like we just have written helpers that do all that and are chainable. So you can still kind of write tests in that way.
Amos: Yeah, but you have to view it from, viewing it from that outside world though, and not being able to dig in is more like a user and you're making more assertions to the guarantees that you're giving your user.
Chris: Yeah. So it's, that's my take on it is I would much rather just like, you know, hit the API, give me a real server, put it on a port. I'm a, I'm going to start sending it some web requests. Absolutely. That's my, that's my hot take on that.
Amos: I just realized what time it is. I do have a hard out today.
Chris: Okay. That's fine.
Amos: Uh, I know that, look, we talked about how this, this was the most planned episode. We didn't even talk about what we said we were going to talk about.
Chris: Yeah, we literally just, yeah, we never even got there. We didn't talk about Nix.
Amos: Nix.
Chris: Nichts!
Amos: Are we sure its Niz, like a xylophone is, or do you have to have the Y to be Niz?
Chris: I think it's, I think it's a, I think it's a Greek, it's a Greek X, which is the same, so it's-
Amos: Oh, okay, perfect. Nech. Necht. I'm in, uh, I'm I, well, I think we can say a little bit about it. You want to say a little bit about it?
Chris: Math.
Amos: Yeah. Using your GPU too, right?
Chris: It's it's a, it's it's a math man.
Amos: It's like TensorFlow. Enjoy.
Chris: Yup. It's a compiler.
Amos: Yeah. I seriously, I just like read the blog post right before we started. So I'm, I'm still, I'm going to go play today. That's my Noggin Day today is to go play with that.
Chris: Cool. Cool. All right. Well, enjoy your day. I, uh, we have some news coming up soon. I've got news. We've got personal news. We got news. And we're going to be, uh, at, uh, CodeBEAM.
Amos: CodeBEAM Virtual America, right?
Chris: CodeBEAM Virtual America. The virtual, virtual one, not the real one, not the blasted hellscape that is the actual America, but the virtual one with sunshine and rainbows and unicorns.
Amos: That's right. It's going to be great we're, we got the final keynote. That is, I don't know how we deserve that, but I'll take it.
Chris: Yeah. We're going to just, uh, do our thing up there. So it'll be fun. We'll be there. I've got some personal stuff. I'm announcing here soon. And, uh, you're, you're on a new project. It's gonna be good and we'll be there and be back soon. She's on, she's wrapping up a project.
Amos: We're working on some stuff to get Anna back on the show. Um, and we do, if we, we tweeted about it, but if we have a 20% discount code for CodeBEAM, so if you can't find it on our Twitter account, tweet at us and we'll send it to you. Alright, sir. I guess it's time to go.
Chris: Yep.
Amos: Alright. Talk to you later.
Chris: Later.