I am writing a Jest/RTL test for a React component that invokes another component. I want to mock that second component so I can have it do things like invoking callbacks that the first component passes to it.
But there is nothing specific to React about this requirement: it comes up for non-React modules, too. I have an approach that I have shown to work using trivial modules and I want to document it here for myself and anyone else who finds it useful.
In a project we’re working on, a Java source file is auto-generated: method names on the interface that is generated (ready for implementing) are based on the HTTP method and URL in the RAML.
The result is this:
What we have here is a single identifier that, at 83 characters in length, is too wide to fit in standard 80-character-wide terminal.
File under “Why Java Is Not My Favourite Programming Language”.
(No, there is no reason why a similar identifier could not in principle be generated in some other programming language. But no other language has the programming culture that make such things possible.)
Those of you who have been reading this blog since 2nd March 2010 — just three days after the blog was born — might remember the fourth post I ever made here: Learning a language vs. learning a culture, on my switching from Perl to Ruby. Way back then, I wrote about “ScottKit — my first non-trivial Ruby program”. Here it is!
This just in:
Failed context type: Invalid context `paneset` of type `Paneset` supplied to `Paneset`, expected instance of `Paneset`.
Oh, the joys of front-end development!
(My best guess: I have two slightly different version of stripes-components library that provides the <Paneset> component in my application, and somehow I’ve got hold of one from the wrong instance.)
At the moment, most of my actual coding work is in Java — which is a novelty for me, as it’s not a language that I am naturally inclined to like. But as I’m coming to grips with it, I’m finding that Java in 2015 is a rather more pleasant language than the one I wrote a CQL parser in back in 2002. The main problem with it is the culture, and in particular the huge vocabulary of patterns, which takes a long time to learn.
So here is today’s brief lesson, which is on dependency injection. Continue reading
My travails with functional programming have been a bit of a recurring theme on this blog, and I have to admit that my attempt to learn Scheme has stalled, more than anything due to all the other things I’ve been doing. I’m sufficiently aware of it to feel guilty, but not sufficiently to actually invest the time I ought to into actually learning it.
But today, Togore Smith wrote a brilliantly insightful comment on one of my oldest posts (Closures, finally explained!), and it’s got me thinking about this subject all over again.
Let’s start by thinking about a very simple example. I’ve recently switched to using Ruby as my language of choice, after a decade as a Perl hacker. Ruby does a lot of things more nicely than Perl, including having proper object syntax, simple everything-is-an-object semantics, a sweet module/mixin scheme and very easy-to-use closures, so I’ve mostly been very happy with the switch. In so far as Ruby is a better Perl, I don’t see myself ever writing a new program in Perl again, except where commercial considerations demand it.
I just wrote an entry about a hard-to-find bug on the blog of my employer, Index Data. It turned out to hinge on the different API expectations of programmers in low- and high-level languages — specifically C and Ruby — and I think it’ll be of interest to most Reinvigorated Programmer readers. Enjoy!