software testing – Rachel Geist

Hi All,

Just wanting to say hi while we’re in September. It’s been pretty busy at work and with Ellie being schooled again. ‘Twas the longest spring break ever. . . I’ve been doing a lot of work in React recently , which sometimes feels like, “yes, I’ve got this!” Then I have to deal with modifying state and then it’s all, “NOPE. What the world in the heck is going on??”

Here are a few of my observations with React after muddling around in it a while.

Why does wrapping my component in <> and </> magically make it work??
- Turns out it’s called a React Fragment and it’s for letting you return multiple children without jacking things up. Please see link for less janky explanation.
Why is testing it so convoluted?
- This is probably on me. I’m getting better at some parts of testing React, but it’s still mysterious.
- It seems like you want to test the workflow rather than if X == Y specifically. So like if you click a button you want to make sure that when you do click it, all the things you want called and done are actually called and done.
- Mocking is your friend and don’t try to test too much in one component. So if your component is calling a permission checker, only test up to the point where the permission checker is called and that you do call it. Then test the specifics of the permission checker in a new test.
State variables are cool, but it’s kind of tricky to debug them.
- Just go and read about State Hooks. I don’t have a super firm grasp on it yet, so this here is mostly reference for me.

React isn’t really one of the things that I thought I’d be learning, but here we are and while parts of it are fine (I’m better at writing components) other parts are still just tricky to deal with (adding in redux for one). BUT! I’m learning and getting better at it and my goal is to not have to ask questions about the same thing over and over, which I hope I’m accomplishing.

More next time!

-Rachel

It’s been a bit since I’ve been here, but there really haven’t been many updates in regards to new and exciting topics in the working realm for me. One thing that I have wanted to cover is Python Testing. Not necessarily how to do it, but the motivation behind writing good tests. Am I an expert in test writing? No. Have I been learning what makes one test better than another? Yes (hopefully). Here’s a few thoughts I have regarding testing.

Be very explicit with naming your test function. When your tests run you’ll see the names and if they’re all called testX, that’s not super helpful. Try something like test_blue_cat_food_bowl_half_filled_hungry_cat. Or whatever. Even if you don’t love the name I made, you know you’re testing how the blue cat food does with a hungry cat and a half full bowl. Use docstrings to then describe in more detail what data you’re setting up for the test and what you’re calculating and expected results.

# not using decorators or anything here for this illustration
def test_blue_cat_food_bowl_half_filled_hungry_cat():
    """
    Tests that the cat will eat the cat food in the bowl.
    One bowl, blue food, one cat, cat's hunger level is hungry
    """

Have your actual testing test only one idea at a time. Say you also need to test to make sure you have the right breed of cat. Make a separate test for that. Sure you could go ahead and test for it in this test, but that’s not within the scope of your function name. Plus if that part of your code breaks in regards to the cat breed, you’re going to have to update more than just that one test that deals with checking it.

Ensure you’re data is set up correctly. Your test may pass, but you may accidentally have something in your test assuming that you’re always being given a full cat because that’s the default cat setting in your factory or whatever. Make sure that anything you’re testing, you explicitly define the test values so you’re not getting false positives.

Test the small things first and then work up to more complex testing. You may want to just set up your one test that is supposed to test everything is summed and converted correctly and just figure that it will pick up the small things. I’ve found this is not the best way to start off. Writing lots of smaller, specific tests to test out all the smaller building blocks of the larger bits of code that use those blocks has proved to be way more effective. It’s also a plus that if you know all your simple cases work and a more complex test fails, then you can narrow down what is going wrong a bit easier too. Which also goes back to my earlier point that if something breaks then you are able to fix that little bit way easier than in your mega test.

Those are the big things that I have learned are super important with setting up and writing sensible tests. It’s pretty easy to find out how to write a test syntactically, but unless I’m just lazy with my Google searching, it’s a bit more difficult to find good references on what makes a good test. Anyhoo, let me know if you have any other testing wisdom!

-Rachel

Rachel Geist

Tag: software testing

September Pop In: React Tidbits

Python Testing: A Philosophy