I recently shared an overview article about Stubbing External Services in Rails. I found it when looking for the best way to stub a pletora of services in a microservices environment. Sure, docker (or whatever) everything and run it locally / in your test suite. But unless you've plenty of disk- and memory space, this isn't always a viable option. The alternative: simulate the service. Mock or stub the endpoint.
The go to gems are Webmock, which catches request and allows you to define the responses explicitly and VCR, which allows you to record responses, and play back.
VCR is quite cool, but as it is a recorder of earlier responses, there may be a lot of noise to dig trough when trying to make the responses a bit more generic (dealing with random token requests and what else)
For testing I pers…
Cypress is a new, open source integration test runner for modern JS applications (its development is sponsored by their online dashboard that allows you to record test-runs). It doesn’t require setting up Selenium, or other browser plugin, manually. Add it to your package.json and everything you need will be set up:
npm install cypress --save-dev
You can open even a GUI using:
./node_modules/.bin/cypress open
Alternatively, you can run the tests headless using the run command:
./node_modules/.bin/cypress run
Running the test will leave you with video recordings of what has been happening visually on the frontend for further review.
Ok. All nice, but you're right, these are tests running against a locally run server. So let's move the examples directory out of scope of the test runner:
mv cypress/integration/examples cypress/integration-examples
*(when exploring a new framework, I typically like …
Still (2013) a great talk by Sandy Metz on testing, and how to do it right, without getting too theoretical. While this talk is on ruby, and it uses a Rails framework for testing, it really is applicable to any other language (only the syntax will probably be a wee bit shittier ;))
Watch Rails Conf 2013 The Magic Tricks of Testing by Sandi Metz on YouTube
(and while unit-testing is between brackets, in general, being a minimalist when writing code really is a good idea)
When you don’t train and eat you grow fat. When you grow fat it’s hard to move fast and swiftly, to be agile. To stay lean many decide to train, but training costs effort.
You can have fun and hack around with your friends cq. colleagues (which is what “Individuals and interactions over processes and tools” seems to suggest), but if you just drink beer and have fun, responding to change will someday become hard. You run fat, how agile your weekends of hacking may seem.
The end-goal of agile software development is continuous and fast delivery of better software, no matter how you’d like to define that. But to stay agile requires training. Not only adding features (consuming feature-stories) but also continuously sharpening the tools that support the process, automate the process. Developing software that supports it to such extent that the process becomes a no-brainer. Hence, proper tooling over (manual) processes: automated tes…
I like Rails, but one thing that Rails falls short in is Javascript dependency management.
While Rails Assets, a proxy that allows for listing Bower packages in your Gemfile makes managing front-end libraries good enough for most front-end work, RailsAssets itself is mainly addressing asset management; it doesn’t allow for integrated management of additional development tools and binaries, useful for e.g. JavaScript-testing (besides the fact that Bower is kind of considered to be deprecated these days).
There are different ways of bundling Javascript, but since Rails 5.1, yarn is the defacto choice for Rails.
You can install yarn either trough npm npm install -g yarn, or if you’re on a mac, using homebrew: brew install yarn. I chose the latter.
To prepare your rails project run rails yarn:install.
There are [different testing fram…
Eerder schreef ik al wat over technische schuld. Het niet hebben van automatische tests wordt vaak beschouwd als een technische schuld.
Testen doe je om er zeker van te zijn dat iets werkt dat het goed werkt. Automatische testen maak je (of laat je maken) omdat zeker weten dat het goed werkt veel tijd kost. Wanneer je applicatie vaak nog wordt veranderd wil je er immers ook zeker van zijn dat het ook blijft werken. Automatische tests zijn kleine programmaatjes die testen of onderdelen onafhankelijk (unit-tests) of in samenhang (integratie-tests) goed werken.
Bij unit-testen worden kleine onderdelen afzonderlijk bekeken of ze nog werken. Zo kan bijvoorbeeld steeds worden gecontroleerd of de bedragen in een offerte wel nog steeds netjes worden opgeteld, en een andere of er nog wel het verwachtte btw bedrag uit blijft komen.
Bij integratie-toetsen, of syst…
De software wereld zit vol met Engelse begrippen. “Technical Debt” is ook zo’n begrip. Maar wat is het?
Een dag geleden zag ik dit bericht waarin Technical Debt werd vergeleken met een continue slecht gestapeld Tetris spel. Een rake vergelijking: als je niet oppast wordt de technische structuur van een applicatie een stapeling op zichzelf oplosbare problemen, maar vormt het in z’n geheel een nagenoeg niet te redden constructie.
Technische schuld wijkt af van financiële schuld. Om financiële schuld te maken moet je geld lenen van een ander. Technische schuld ontstaat doordat er geen tijd wordt gestoken in het goed op orde maken van de techniek. Zo is het een goede gewoonte om kritische zaken en/of zaken die erg foutgevoelig zijn in de applicatie te voorzien van automatische tests (“kan die rol wel/niet bij die gegevens?”, “gaat het ook goed als hier een negatief getal …
Dit artikel van murblog van Maarten Brouwers (murb) is in licentie gegeven volgens een Creative Commons Naamsvermelding 3.0 Nederland licentie .