A few weeks ago I learned an important lesson that I’d like to share: When building unit tests, never use a mock/stub unless it’s absolutely necessary. Let me explain with a little example.
Let’s say you’re working on a large project and you start developing Module A, which uses a MySQL database. To write a unit test for this module, you’re going to need to mock the MySQL queries. I have used sinon for this purpose and it’s worked great by the way. You typically don’t want your unit tests accessing a real-life database server, so using a mock here makes a lot of sense.
Now let’s say you’re adding a new Module B to your project, which uses Module A. As you’re writing the unit tests for this new module, I highly recommend NOT mocking Module A. You should instead continue to only mock the MySQL module as you did when testing Module A.
The reason I recommend this is that every time you mock an interface, you’re usually replacing the real code with a very simple imitation of it. You might have the mocked Module A always return success or failure, depending on what you’re trying to test in Module B lasix australia. However, you’re very likely to miss out on a lot of detail. It’s highly unlikely that the mock will validate input formats and data structures for example.
By over-using mocks, you end up accumulating technical debt in the form of bugs and implementation errors that will only show up in E2E/integration testing. Debugging in unit tests is typically faster and easier than in an integration environment, so we definitely want to catch as many bugs in the unit test as possible. Unit tests will never catch all the bugs, but minimizing the use of mocks will help you catch more bugs at that stage.
When I first started developing the Sift Science for WooCommerce plugin last year, I needed interactive controls on the Orders page that displayed fraud scores and allowed the admin to flag fraudulent users. I didn’t want to reload the page every time the user took an action, so the obvious solution was to implement some client-side scripting and background Ajax calls to the server.
The goal was to add a new column to the Orders page that contained small icons that displayed the score and a couple of other icons for the user to click like so:
My initial implementation was all in jQuery, and it was ugly. In PHP, I rendered all possible icons with the CSS tag
display: none. I then used jQuery to turn those icons on and off as needed, and talk to the server via an <a href="https://github.com/Fermiac/woocommerce-siftscience/blob/b8fa7787ac19622b1670acc1094c1f1e63204a3a/tools/wc-siftsci-order buy generic lasix.js”>endpoint in the plugin.
Having UI logic in both PHP and jQuery meant that the two had to stay closely coupled. On the other hand, I supposed I could have just rendered an empty
div in PHP and made jQuery add all the HTML, but using jQuery to render all that display was not appealing.
Late last year I joined Automattic and early this year we started working on Connect for WooCommerce. For this project, we are heavily using React (and wp-calypso as a framework). As I got more comfortable with React, I started thinking about the possibility of using it in the Sift Science plugin.
I started out by implementing a new feature in React to see if it was feasible. I implemented some basic admin functionality in the plugin settings page. When that went smoothly, I decided to take the leap and port all the jQuery code to React.
All-in-all, I’m happy with the switch to React. That said, I’m not convinced that this is the best approach for everyone. Here are some pros and cons:
- Once you get used to the new paradigm, React code is more readable than jQuery
- All the UI is in React and the PHP endpoint can act as a data-only REST API
- You can leverage NPM modules to perform complex tasks
- You have to learn React, which can be intimidating
- You have to “compile” (webpack) your code before releasing it
- Initial setup overhead (npm, modules, build tools)
I am pleased to announce that the Sift Science plugin for WooCommerce is finally ready for beta testing! Lukas and I started this plugin over a year ago and have been working on it off and on as time permitted. But I’m happy to say that it’s now good enough for Beta testing.
Note: I work for Automattic on WooCommerce. This is a personal side project.
What is Sift Science for WooCommerce?
Sift Science for WooCommerce is a plugin that integrates Sift Science fraud detection into your WooCommerce online store. To use this plugin you need to have a WooCommerce online store and an account with Sift Science.
How does the plugin work?
The plugin sends order information and user behavior details to your Sift Science account which is then used to give orders scores that predict the likelihood of fraud.
What information do you send to Sift Science?
I will eventually put together more formal information about this, but for now you’ll have to look at the code to know what data gets sent. Sorry visit this page.
What does Beta mean?
It means that the software’s basic functionality is working. However, it hasn’t been extensively tested and there are still a few features that aren’t finished.
What does Open Source/GPL2 mean?
It means that you’re free to copy, use and modify this software. Read here to find out more.
Wait a minute. Don’t you work for WooCommerce?
Yes, I work for an amazing company called Automattic and I work on WooCommerce. However, this is a project that began before I joined the company and is not officially linked to WooCommerce. It is a side project.
How can I help?
This is an open source project that I’ve been working on in my spare time. There are two main ways you can contribute:
- Testers are highly welcome! If you can install this, try it out and provide feedback on bug reports that would be great!
- If you’re a developer and would like to contribute, feel free to either contact me to collaborate or submit Pull Requests that fix specific bugs.
There will be a credits/thank you section for contributors 🙂