It can be useful to get code coverage for a manual test set in order to check that you’ve covered all the cases for the code you’ve written. Getting this is similar to the process for getting coverage for an integration test.
Not having a smartphone, I’m more aware of the changes brought about by COVID that assumes everyone has one (that’s fairly recent, and that’s on a data plan or can access local Wi-Fi). My local bus stop no longer posts times, instead having a QR code / NFC which presumably sends you to a website with the times. This is going to be more certain to be accurate – I expect they’re changing them more frequently due to lower use – and can be enhanced with the standard “when will the bus get here” approximations which are common online or on the text screens in more central bus stops.
NodeJS offers the ability to overwrite methods and values in imported modules. This can be useful for testing without dependency injection, for example if you have a large amount of legacy code, and you don’t want to refactor the architecture before the unit tests are in place.
Dependency Injection is a software pattern where you pass dependencies to an object, instead of creating them inside the object. Around a decade ago, it became very popular to use dependency injection for everything – not only for swapping out dependencies at runtime (the problem it was the solution for initially) but for creating a dependency with a particular lifecycle (e.g. singleton or once per session for a webapp), replacing dependencies for testing, and even for instantiating dependencies which were always going to be the same, which were “injected” as the concrete class and “registered” as the same.
It can be useful to import a module for a single session without saving it as a scratchpad, or to be able to use it against a webpage.
Assume we have a document obtained from a database as a JSON object, and we want to add additional properties, or override existing properties, preferably without modifying the original object.
From until the 1970s until about the 2010s, the “right” way to oppose racism was to be colour-blind – to avoid considering race as much as possible, and perhaps to even argue that it didn’t exist. Nowadays, the concern is systemic racism: the observation that even our attempts at colour-blindness haven’t lead to equal outcomes, and so the institutions (and the people in them) may be inherently anti-black in a way we didn’t notice before. Recently, “anti-racist” has become suggestive of “pro-black” – treatment like affirmative action, or quota systems, or treating minority students in a way that reflects their unique life experiences are the ways to go. Unfortunately, this conflicts with the legacy definition of racism as “treating people differently depending on their race”.
The problem is to display a loading spinner while requests are in-flight. The complexity is that everything’s event-driven, so the components themselves don’t know when this happens. A solution to this complexity is to use RxJs or some other event management system.
While converting our backend REST API integration tests from Cucumber to JUnit, I saw the chance to simplify our rollback of test data.
At Lhasa on the Kaptis project we used Jenkins declarative pipelines to build, test and create artifacts after every commit. Here I note down some things I’ve learned.
Angular allows creation of reusable components to simplify development. I created an input component in order to simplify how the HTML form pages looked (it allowed a large block of code to be abstracted and replaced; later it allowed all the error texts to be put in one place instead of being repeated for each field).
I find the Spring documentation generally comprehensive, but most useful after you already know the right answer to your questions. Here I note down some things I’ve learned this past project.
Cucumber allows you to rerun failed tests by defining a test runner that specifies the features to run to be those with failed last time, as output by the built-in rerun plugin. We wanted to fail the build entirely if too many tests failed the first run, as we found tests weren’t being fixed (they would always fail the first time, refresh the database, and pass the second time: some earlier tests weren’t properly cleaning up after themselves).
Edit 18th May 2020: I’d now recommend just using
@Disabled("Ticket XX-111")instead of having an entirely separate annotation with different behaviour. This means that you can search your codebase for the presence of disabled tags with closed tickets, and I think the tradeoff of this not being automated is worth the gain of not having another annotation and not running tests every build that aren’t expected to pass. You could automate this with a nightly job, for example: run through, find all references to tickets, look on JIRA to see if they’re closed, maybe make some metrics as to how long tests stay in this state.
I’ve encountered many systems that were poorly documented (or entirely undocumented) that I’ve had to figure out in the course of my work. Sometimes I get lucky and there’s somebody still in the company who understands what’s going on and can explain it to me. Sometimes there isn’t.
In Cucumber 2 and below, you could reference classes containing primitive elements in step definitions, and data tables would be mapped automatically.
The Angular documentation on validation mentions that there exists an AsyncValidatorFn counterpart to ValidatorFn, but doesn’t give any details in implementing it other than the function prototype. You can guess that it’s similar to ValidatorFn in the same way that AsyncValidator is similar to Validator, and this turns out to be correct as far as I can see.
At work on Thursday, we encountered a particularly thorny issue. I think it would be beneficial to write up a log of how I attempted to solve the problem, what went right, what went wrong, and what I could have done better.
We’d been having problems with this feature branch already. It was supposed to change the behaviour on logging in to redirect you to where you’d been just before. It worked fine locally, but failed on the build server.
I read Paul Graham’s essays when they get linked on the other blogs I read, which is semi-regularly. The Bus Ticket Theory of Genius has just showed up on Hacker News, wherein Graham argues that to do great work requires natural ability, determination, and an obssessive interest in a particular topic, with the last one serving as a good proxy for either of the first two.
Last week, I designed an icon using two separate overlapping SVG icons (a flask with a line through it). This was to represent whether to show or hide assays (on a graph of assays and key event relations), and I wanted to fade out the icon if assays were hidden. I tried this using
color: rgba(255, 255, 255, 0.5)for both icons. This didn’t work:
I’ve recently joined an organisation that uses Forcepoint to monitor and SSL bridge all HTTPS connections. This means that connections to GitHub over HTTPS fail, as the GitHub certificate is replaced with Forcepoint’s, with the error message
I use Firefox at work. Unlike the prime focus of their advertising campaigns, I’m not interested in the privacy protections. I use it primarily for two features that haven’t yet made it to Chrome – containers (cookie isolation) and tab hiding.
Some languages, such as C# and Kotlin, allow the declaration of extension methods – new methods callable on existing classes, without needing access to the original source code. Some languages, such as Python, go further and allow you to modify the behaviour of existing function calls (known as “monkeypatching”).
One of the most important things I learn from demos and show & tells are frequently not what the presenter meant to put across, but all the minor things that show up when they’re setting up their machine, and moving around it to show what they need to. Windows has a way to disable notifications? What’s that editor? Woah, how’d you format that file? Outlook has a dark mode??
Many companies put tech challenges (to be completed when applying for the job) on the public web. If there’s a challenge on GitHub, there’s a good chance that people will put their solutions on GitHub as well, which can be useful to compare your own solution against / take inspiration / blatantly cheat.1
subscribe via RSS