I’m pretty into mocking…though I went overboard years ago when I really first started implementing it in my tests. Now-a-days I keep it under control, really only mocking external services. If I must mock part of my own API (e.g. for performance reasons) I make sure I minimize the mocks per test.
In Python I’ve extensively used the mock and request-mock packages. They’re great, but I find their APIs a bit clunky. Lately I’m doing more Node.js and needed to mock an HTTP request and response. Continue reading “Nocking”
I’ve been refactoring an internal application that we use extensively at my organization. It’s called Sanity.
It is a general-purpose HTML quality checker that’s ostensibly for testing accessibility, but it’s general enough that it can test all kinds of things Continue reading “When Stringifiying a DOM Node Gives You Too Much”
The aim of this post is to show that recent trends in Agile trainings, emphasizing improvisation over principles, can do a great disservice to teams and projects.
Using Agile buzzwords doesn’t mean a successful product, results do. When organizations attempting Agile don’t strike a balance between flexibility and discipline, the Agile process is often blamed, not its crappy implementation. For an Agile process to succeed it takes knowledge and discipline to stick to its guiding principles. It’s not “Agile” to fly by the seat of your pants. It’s just irresponsible. Likewise, it’s not “Agile” to be dogmatic. After all, our goal is to produce the right product at the right time, not “be Agile”. Continue reading “Principles First”
Flaky automated tests are a real drag. They’re worse than no tests at all. That being said, you can take measures to eradicate them.
Where I work folks have (finally) become test-infected, which means non-dedicated testers are writing unit, and even functional tests for themselves. Because of their lack of testing experience, a lot of these testers write tests, run them once, and bask in the green. The test may happen to pass the first time it runs, then he/she commits it to master and all’s well, right? Continue reading “Deflaking flaky tests”
Note: I no longer use Jekyll for my blog.
A lot’s been written about Jekyll, but coming from a Python background and knowing virtually nothing about the Ruby ecosystem, I had no idea how to do Ruby virtual environments and install Ruby dependencies. I suppose I’ll learn more about that as I need to. In the meantime, I just wanted to get up-and-running with Jekyll and be able to build my environment from my website’s Github repo.
I documented how I did this in my website’s Github repository’s README, so check it out. Hopefully this will save you time getting going with Jekyll, and also allow you to easily re-create your environment on other machines.
Though I am not a QA engineer, a year ago frishberg, hellmanj and I took it upon ourselves to help NCBI’s QA department replace their dying automated web testing framework, IBM’s Rational Functional Tester(RFT). The process introduced some innovative new tools that we released open-source, but perhaps more importantly, it introduced new practices to our QA group. In this post I’ll discuss our experiences with developing our own testing framework and our experience integrating some programming-best-practices to our QA group. Continue reading “A new web-testing paradigm: Robot Framework & Page Objects”