Houzz.com

Houzz API Tests at a Glance

As a fast-growing company, we have an increasing number of APIs consumed by our mobile apps, internal batch processes, and business partners. Manually testing these APIs each time has become almost impossible given our weekly release cycle. My first project after joining Houzz was to build our API test automation framework. With hundreds of test cases included, this API automation is now a critical part of our release validation. Not only does it save a lot of manual testing effort, it has also caught many critical bugs and has prevented production issues. This system has played an essential role in scaling product development with our growing team.

Where to start?
With a large number of API endpoints, it could be difficult to figure out where to start at the beginning. After some discussion, we decided that it could be cost-effective to build a smoke test for the most frequently called API endpoints. I compiled a list from our production server logs, and built a smoke test to just make these API calls in batch and do some basic validations, such as HTTP status code and schema validation. Although it only took minimal effort to build, it turned out to be effective in catching a meaningful number of critical bugs before they reached production.

Next step is to build a more comprehensive regression test suite. Quite similar to end-to-end UI tests, API tests should also be based on user scenarios. The only difference is that API tests are simulating user scenarios at a lower level without UI interaction. To find out what APIs our mobile apps are calling, we have an internal tool to capture HTTP requests between our mobile app and API server, including HTTP method, url, query parameters, headers, request body, etc. As I go over each user scenario, the API call flows are being recorded. What’s left is to convert these recordings to API tests by extracting test data, calling APIs and adding validations. Please see the chart below.

image

Use test tool or write code?
There are two popular approaches to automate API tests: one is through UI based API testing tools, such as SoapUI; the other is to write our own automation code with some open source libraries. I decided to go with the latter approach because of the following benefits:

  • more reliable
  • independent of OS
  • better code reusability
  • easier to debug
  • easier to customize
  • easier to integrate with internal tools and other projects

I chose Java to build the API automation framework, and use TestNG for test execution and reporting.

How to automate API calls?
To quickly generate some automated API test flows out of the recorded request data, I wrote an utility to extract request data into JSON format. For example, an API call to get photo by id (GET http://www.example.com/photo?id=1001) could be parsed as the following JSON data:


{
    "method": "GET",
    "baseUrl": "www.example.com",
    "path": "photo",
    "queryParams": {
        "id": "1001",
    }
}

JSON data is later deserialized to RequestData Java objects, which could be used to build API requests. Definition of the RequestData Java class looks like this:

public class RequestData {
    private HttpMethod _method;
    private String _baseUrl;
    private String _path;
    private Map _queryParams;
    private Map _postData;
    private Map _headers;
    …
}

Often times, the same API endpoint will be called multiple times with different variations. JSON data generated from the first request of the same endpoint will be used as a baseline. We don’t need to record the full JSON for subsequent requests of the same endpoint. Instead it will be parsed as a JSON diff. Using the same example of “get photo” API again, let’s say we need to make the same API call with a different photo id “1002”, it will be parsed as:

[{"op":"replace","path":"/queryParams/id","value":"1002"}]

The json-patch library (https://github.com/fge/json-patch) is very useful in this case to generate JSON diff and to reconstruct original JSON data.

Compared to a UI test that requires a browser, for API tests we need a HTTP client to handle request and response.  I’m using Apache HTTP component for that purpose. In order to parse and validate API responses, I use JsonPath and XmlPath from REST-assured, which provides an easy way to access field values in API responses to verify its existence, data type, and expected value.

What to validate?
Now that we have automated making API calls and parsing the response, we also need to perform some validations. Often times different API endpoints or test scenarios require different types of validations, but there are some common ones that almost always apply:

  • Status code, schema validation
  • Verify API response is what the client is expecting. Still using the example of “get photo” API, a client calling this API may be expecting a string field called “url” in the API response that points to the photo’s URL. Assuming a valid photo id is provided, the API test should check that “url” field exists, its data type should be a string, and its value is a valid URL (if you know what is the expected URL for a given photo id, you could also do an exact match on its value).
  • Verify expected effect after making an API call. This is similar to UI functionality test. One example would be after calling an API to add a new photo; if the response is successful, you want to verify the photo is actually added on server side. Usually you can call an API to get the newly created photo to verify this.
  • Cover negative cases in testing. Since we cannot control how clients make API calls once we expose them, we want to make sure API behaves correctly with invalid input such as missing required fields or incorrect data types, and API response should include an error message informative enough to tell client what is wrong with the API call.

Performance
In addition to functionality, we also want to test API performance. One important aspect of performance testing is to monitor latency and resource usage of a single API call. API tests record latency of each call and flag calls with latency higher than a threshold. To monitor resource usages, our backend engineering team implemented a performance logging mechanism to log performance counters for each incoming request (examples include memory usage, and number of sql or solr queries). I integrated API tests with these performance counters to find out if there is any significant increase caused by code change. Basically an API test would make the same API call to two different builds - one is the current development build, the other is from the latest release - and will then retrieve the performance counters for each build and make a comparison. This has helped us detect several performance regressions such as increased memory usage or redundant sql/solr queries.

Backward compatibility
We certainly don’t want to break a previously released mobile app when we roll out changes on the server side. Our users should be able to use the Houzz app regardless of whether they upgrade to the most recent app version or not. Therefore, we need to maintain API tests for some previously released versions. Since both API request and response could be different from version to version, there will be some additional maintenance effort.

To run API tests in different versions, test data is separated into resource files categorized by version if necessary. Based on system property, our test framework will simulate requests with different versions, and pick up different test data resource file accordingly. To determine which versions to maintain, I often need to check production logs to find out which versions are mostly being used by our users. We run API tests more frequently on current version and most used versions, and only check older versions on release day.

Internationalization
With users from all over the world,  we need to test our API endpoints in different countries. In addition to localized language in API response, functionality could also be slightly different in each country. For example, searching “red sofa” related photos could result in different content for different countries. Similar to how we handle versions, we also extract locale specific test data to files grouped by country code. Our test framework is able to pick up correct data file based on locale.

Integration with UI automation
One additional benefit we realized after building the API automation is that, we can leverage them in end-to-end UI automation to speed up test data setup. For example, a significant percentage of our UI tests require a newly created user. Instead of signing up on browser, we now switched to creating users via API. This has several benefits:

  • significantly reduced UI test execution time as API calls are usually a lot faster than UI flow.
  • improved overall stability of the UI automation. One of the reasons is that the UI changes are usually more frequent. For example, if we are iterating different UI designs for sign up flows, all the UI tests that require user sign-up through UI could fail. This is no longer a concern after we switch to creating user via API. One caveat is that you should keep at least one test to cover the UI flow replaced by API elsewhere.

Summary
It has been a very exciting experience to own a project from the beginning and build it from scratch. Of course I also received a lot of help from my amazing coworkers along the way, and it’s always fun to collaborate across the team. As Houzz grows, we will face new technical challenges that provide more exciting opportunities in the test automation area. If you’re interested in joining our growing team, please check out our jobs page at https://www.houzz.com/jobs.

New Bedroom, New Style

image

Contemporary Bedroom

It’s out with the old and in with the new style when it comes to master bedroom upgrades, according to the 2015 U.S. Houzz Bedroom Trends Study. Before our master bedroom renovating and decorating projects, most had a traditional style or no particular style at all (64%). Post-updates, most of us opt for transitional, contemporary or modern styles (45%).

image

Bigger is better when it comes to our updated master bedrooms and their closets. Of those of us  renovating our master bedrooms, one in five is expanding its size (21%), and more than half of our closet upgrades involve an increase in square footage (59%). One-third of updated master bedroom closets are growing by 50% or more!

image

When it comes to decorating, the majority of us are using small décor accessories to update our rooms (76%), yet half of us are also replacing furniture (49%), and a third of us are updating our beds (37%). One in five new beds is a platform (23%), with standard and sleigh beds following as the next most popular styles (15% and 13% respectively). Examples of platform beds available for purchase on Houzz can be found here.

image

To further customize our beds, many of us are accessorizing them with accent pillows – many, many accent pillows. Forty percent of our beds will have five or more decorative pillows once our master bedroom updates are complete!

Check out the full 2015 U.S. Houzz Bedroom Trends Study for more details from the report. And if you have products you’d like to see featured on Houzz, contact shopfeatures@houzz.com.

Houzz Acquires GardenWeb from NBCUniversal, Welcomes the GardenWeb Community to Houzz Family

We’re excited to share that Houzz has completed the acquisition of GardenWeb, the longstanding home and gardening community, from NBCUniversal. The GardenWeb and Houzz communities have a lot in common with regard to our shared passion for our homes and gardens.

Since it was founded in 1995, the GardenWeb community has been a bastion of home and gardening advice on the Internet. Bringing GardenWeb’s vibrant and engaged users, forums and resources together with the Houzz platform will provide a richer content experience for the unified community. 

The addition of GardenWeb gives Houzzers access to over 2.8 million discussion threads, over 14 million discussion posts, and nearly 400 discussion topics for both home and gardening enthusiasts. Millions of people participate in discussions on Houzz every month to provide and find advice for their home renovation and design projects. 

Our team has been hard at work to complete the first phase of GardenWeb’s integration onto Houzz. Welcome to the Houzz family, GardenWeb!

Inside Houzz Tour: Tel Aviv!

image


The Houzz team in Tel Aviv shared a glimpse of their warm and welcoming new office. Full of light, color, and plenty of areas to collaborate, the space provides a fun and comfortable environment for Houzzers to work and even play!

Here are a few photos of the gorgeous space:

image

The bright and inviting lounge is often the location of the team’s weekly standup meetings

image

An airy, open floor plan creates a collaborative environment for the team

image

Large windows throughout the office offer plenty of natural light and spectacular views of the city

image

The instruments in the Music Room aren’t just decorative – with a few musicians on the team, they are also used for spontaneous jam sessions

image

The Bathroom and Kids Room are popular meeting spaces

image

Houzzers enjoy meals and Friday happy hours in the dining area

image

The Houzz Tel Aviv team

Photography: Uzi Porat

Houzz App for Android Gets an Update

image

Android users will find a redesigned Houzz App available on Google Play™ today that makes it easier to discover key features on Houzz and collaborate with others on projects. With today’s update, the Houzz App for Android also doubles the number of countries supported with the launch in Russia, Japan, Italy, Spain, Sweden, and Denmark.

The new version of the app makes it easier for Houzzers to:

  • Discover key Houzz features – Photos, Find Pros, Stories, Advice, and Shop – through new navigation. A new scrolling homepage lets users scroll through photos, view similar photos, and save their favorite ideas.
  • Share and collaborate on home projects and manage ideabooks with an enhanced “Your Houzz” experience. Users can also now upload photos from camera roll or take a new photo and save it directly to an ideabook.
  • Contact a home professional, right from the app, and browse more visual listings in the professional directory.

The Houzz App is available for download on Google Play here.

Houzzer Profile: Deepa Ramachandran, Full Stack Engineer

image

While Deepa is officially a full stack engineer, she’s touched everything from product-focused releases to business development projects during her time at Houzz. Outside of the office, Deepa can often be found hiking with her husband and their two dogs, or in the midst of a home remodeling project (they are currently working on project #3!).  

What inspired you to go into engineering?
My older brother actually introduced me to coding. I watched over his shoulder as he did his homework for his coding classes…I really gravitated toward it, and started to pick it up. I was always interested in math and science growing up, and coding felt like a great fit for me. I started studying it officially in the 8th grade, around the time my family also bought the first computer for our home.

What is your role on the engineering team at Houzz?
I’m a full stack engineer, but I like to think of myself as more of a product engineer. It gives me a lot of satisfaction to see something go from initial concept to delivery. Especially when there’s a component that’s geared toward Houzzers. I like being able to impact someone’s life in that way.

That’s what attracted me to Houzz…I was a user first. My husband and I were remodeling our home, and Houzz played a major role in the process. Houzz became a language I used to speak with my contractor. We would build ideabooks and show them to our contractor and say, “This is what we want. This is our style.” It completely changed the conversation.

What’s your favorite part of working at Houzz?
The environment, the people. I work with a lot of really smart engineers, who are always looking to help each other. We collaborate really well with one another. Houzz is a flat organization, and it’s a system that works really well because of our people. It’s very refreshing.

Prior to joining Houzz, my experience was mostly working with large systems that were part of even larger systems. It was not easy to see the impact of my work immediately. At Houzz, I get to take something from a whiteboard diagram to a finished product that’s experienced by millions of users – that takes the cake.

What’s your favorite thing you’ve worked on at Houzz?
I worked on a large part of the Houzz marketplace, which really appeals to the product engineer in me. I’ve also worked on projects with a business development element, comparing technologies for a certain use case that we’re looking for. It’s difficult to pick one project as a favorite, because what I really enjoy is the variety. It’s given me a breadth of experience in so many areas.

When do you do your best work?
More so than a certain time of day (though I am more of a morning person), there is a situation that I find I work best in. When you’re working on a project that you find interesting, and with people that you enjoy working with, you give it all you can, because you’re having fun.

What do you do when you’re not working?
i’m usually out hiking with my husband and our two dogs. Our favorite hike is the McNee Ranch Trail in Pacifica…you get gorgeous views of the beach, and it’s dog friendly.

From Dream to Home


Everyone has a dream of how they’d like to live some day.  

For many of us, home is a stage for life’s dreams. It’s the stage for building a family, for celebrating with friends, and for making memories. We know that a home isn’t just about the hardwood floors, it’s about the sound two little feet will make on them. It isn’t about the couch, it’s about who’s going to curl up with us. And it’s not about the perfect garden, it’s about the perfect garden party with those we love. We know that designing a home is really about creating the life you want to live with the people closest to you. At Houzz, this is what home means to us.

Houzz founders, Adi and Alon had big dreams for their home, but they found the renovation process too frustrating and fragmented to make those dreams a reality. They soon realized others shared this frustration, too, and built Houzz to help.  

This week, we’re rolling out our first-ever ad campaign to celebrate home dreams. From a family imagining their cluttered kitchen as an open, airy space where they can spend time together, to a young couple learning the true meaning of compromise when it comes to decorating their apartment. We hope, like the stories themselves, you’ll be inspired to look beyond what is and imagine what could be.

Welcome home.

Inside Houzz Tour: Tokyo!

image


Houzz Japan shared some photos of their new office, which was designed in true Houzz style to bring our fun and collaborative culture to life. You can see the team’s input throughout, particularly in the hardwood floors, which they installed on their own with the help of a few talented local professionals!

Check out a few photos of the beautiful space:

image

A bright and airy lounge doubles as a waiting area for guests

image

An open floor plan helps Houzzers collaborate throughout the day. Can you spot our signature rubber duckies?

image

Houzzers regularly gather in the dining area to enjoy breakfast and lunch as a team

image

Plant-inspired pendant lamps over the dining table bring the outdoors into the room

image

A bar counter serves as the perfect place for preparing tea or coffee… or drinks for happy hour every now and then!

image

An indoor garden provides a peaceful area for a quick break or a casual conversation

image

A recreation space includes a bouldering wall, tent-like hanging chair, and plenty of room for Houzzers to take part in an evening yoga session

Houzzers Tackling Drought, Flooding in Outdoor Upgrades

image

Midcentury Landscape

Water issues? Not in my backyard, according to the respondents of our U.S. Landscaping and Gardening Trends survey. Of the 1,600 Houzzers who are either planning, in the midst of, or recently completed an outdoor project, more than half are updating their yards to address drought (35%) or flooding (19%). Unsurprisingly, these issues are especially prevalent for those of us in California, where 70% of Houzzers updating their outdoor spaces are tackling drought, and in Texas, where 47% are battling flooding.

image

A third of us updating our existing lawns are reducing them (36%), and 16% are removing them altogether. This number jumps to 46% in California, where Houzzers are also twice as likely to substitute their existing lawn for a synthetic one. Additionally, nearly one in five Houzzers nationwide is installing a rainwater harvesting system as part of their outdoor upgrades (17%). Two in five of us updating our greenery are selecting drought-resistant (42%) or native plants (41%).

image

Beyond addressing water woes, Houzzers are keen on creating outdoor spaces that are low on maintenance and high on party potential. Seventy-one percent of us upgrading our outdoor spaces most value an easy to maintain space when it comes to functionality. Areas that are easy to entertain in (60%) and easy for the entire family to enjoy (48%) are prioritized next.

These values make sense, considering how much time we spend outside. Over half of us upgrading our outdoor spaces spend six or more hours there per week (51%). Relaxing (65%), gardening (48%), and entertaining (47%) are the top three uses of outdoor areas.

image

For more insights from the report, see the full 2015 Houzz Landscaping & Garden Trends Study.

Roboticizing the Restroom

Every successful tech startup has to deal with scaling issues. These can include: building a reliable backend, tweaking the product/messaging for greater mass appeal, and hiring the people necessary to accomplish these goals. Houzz has been lucky enough to do pretty well on these challenges, but early success in hiring ended up creating a new challenge - providing adequate facilities for all the employees. Through clever rearrangement of our open seating plan, we were able to accommodate a lot of people in the office until we move into our new building later this year. The restroom, however, was not amenable to the same solution.

The men’s room in our engineering headquarters on University Ave. in Downtown Palo Alto started to hit its limits. Having a fraction of the stalls as in the women’s restroom, the capacity in the men’s room was usually sufficient, but was simply not enough for peak traffic. Lines would form, and less dedicated bathroom goers would simply return to their desks. These people would usually check back occasionally until the line had subsided, but I often worry that some people never made it. Certain e-mails about working from home for the rest of the day still haunt me.

Long men’s room lines became a daily occurrence, but many in the office saw them as portents of something even worse. A few disturbing issues could cause our bathroom infrastructure to collapse. First, there was a small club that prepared and ate muesli together for lunch. The dangers of too many people simultaneously eating a high-fiber lunch at work were all too apparent, and this group was a very evangelistic cult. Another concern was the free meals  Houzz provided employees. With everyone eating the same food, we were always one undercooked meal away from total societal collapse. If we wanted employees to feel secure about the future of the company, something would have to be done.

Planning
A committee was organized to find a solution that would offer temporary relief to this issue until the addition of a second stall. Most of the early suggestions from the committee revolved around usage prioritization. We didn’t have any problems before all of the newer employees joined, so there should probably be a system where older employees are able to either jump the line or eject a newer employee from the stall as needed. These were eventually rejected, as we felt that they might hurt recruiting. Some people felt that they may even cause legal issues.

We then moved on to more technological solutions. Perhaps we could build a reservation system that would allow people to queue for the bathroom from their desks. When nature calls, simply enter your request into the system and wait for a notification that your turn had arrived. We became even more excited by this prospect upon the realization that this system could even be used to auction off peak hour bathroom slots, smoothing demand while creating a new revenue stream for the company. We immediately moved to a conference room with a bigger whiteboard.

Within a few hours, we had a pretty solid design for most of the system. However, we were stuck on how to determine when someone was done using the toilet. A webcam wouldn’t work because there wasn’t an outlet in the stall. Self-report would be unreliable and require the exclusion of visitors who aren’t part of the system. Assigning fixed blocks of bathroom time would be wasteful. After banging our heads on the wall for a while trying to figure out a solution, inspiration hit. Like most problems in life, the correct solution to this would involve robots. We immediately tore the whiteboard containing our now useless system diagram off of the wall and chucked it in the trash.

The requirements for our robot were fairly simple. We would just need something that can detect whether the stall is available and post that information to Slack. We already knew how to post to it, so we were halfway done from the start. A door sensor is a pretty simple device, so pretty much anyone could make that too. Unfortunately, no one on the committee actually knew how to build a hardware device. After asking around the office, it turned out that no one who knew how to build a robot was both willing and able to spend their time on the Toilet Bot project. I still can’t explain that phenomenon.

imagenote that there is no intersection for all three of these

The Hero’s Journey
As someone who had both the time and the desire to build a Toilet Bot, I decided to learn how to actually do so. I enrolled in an embedded systems course online and got started. Within a week or two, I had built my first system that responded to a button press. Eureka! All I had to do was make the bathroom door press a button and I was done. I immediately ordered a Raspberry Pi starter kit. A few days later, I had built a Raspberry Pi system that would post an update whenever an attached button was pressed or released. After a little research online reading blog posts by other startups that had built similar projects, I replaced the button with a magnetic door sensor switch and was good to go.

I brought Toilet Bot 0.1 into the office and got some co-workers to help me install it on the stall. That’s when we realized that the Raspberry Pi has the same fatal flaw as the webcam: it needs to be plugged in! A little searching online revealed that there was no reasonable way to power it with batteries, so we were back to square one. After a little more research, I learned that while a Raspberry Pi was a good small computer, it wasn’t really meant for this type of work. Arduino is what people use for smaller embedded projects like this.

Looking into Arduino, it seemed like it would be easy to do the button detection but not to post an update. After failing to find reasonable and cheap WiFi capabilities for Arduino, I settled on some cheap radio transceivers. Within a few weeks I had built a working system at home in which the Arduino would send a radio message to the Raspberry Pi upon detecting a change in the door switch. The Raspberry Pi would then make the post. Toilet Bot 0.2 was ready. I had even purchased a 9V battery adapter to power the Arduino, as Arduino is a proper embedded system platform.

Before bringing the new bot into the office, I did a quick search online to see approximately how long I could expect the system to run on a single 9V battery. I found some varying information, but none of it claimed more than 2 days of life. To really get good battery life out of Arduino, you need to combine the components yourself on a breadboard, leaving out extraneous parts like the voltage regulator. This project suddenly became way more awesome. Another week or two later, and I had a small collection of capacitors, resistors, wires, and a chip on a breadboard. Surprisingly, it actually worked when I attached 2 AA batteries. Using much less power than the original device and spending most of its time in sleep mode, I estimated that the batteries could last for a year before needing replacement on this device.

Now that Toilet Bot 0.3 was ready, I brought it into the office to be installed with the help of a co-worker. The new stall could be built any time now. We had to hurry if we wanted to get this installed before it was rendered obsolete. After a week of fiddling with the Raspberry Pi to connect it to the office network and make the bot script run on startup, we installed the Arduino breadboard on the stall and created the channel. Everyone was very excited as I documented Toilet Bot’s maiden voyage. It actually worked! We attached a short explanation of Toilet Bot to the stall so that people wouldn’t freak out about seeing strange electronics in the bathroom. We were finally able to move on with our lives.

Victory and Obsolescence
The next week or so was full of adulation. Many of my male co-workers kept coming by to thank me for my heroic installation of Toilet Bot. Some were just blown away by the strength of character it took to install such an ugly device in a prominent place in a design company. We even achieved internet fame when a visitor tweeted a picture of the bot.

image

The results were clear: people no longer waited in line for bathroom stalls. All waiting was now done at our desks until the bot would announce the start of a race to see who could get to the stall first. Unfortunately for the spectators, these races were far more rare than predicted. People would almost always arrive to find an open stall as promised.

Those heady days of Toilet Bot supremacy were never meant to last. I had barely finished installing a database on the Raspberry Pi to track bathroom usage when the contractors arrived to install the long-awaited second stall. Rather than the expected joy of the multiplication of our facilities, I felt a loss at the arrival of this new stall. How could my precious Toilet Bot be so easily replaced?

Not to be deterred, I built a second bot. Noticing that most of the parts were cheaper if bought in larger quantities, I did so and was able to build the second bot at a marginal cost of around $15. Having bought the parts in bulk, I offered to install bots in the women’s restroom. Having more stalls than the men’s, their restroom seemed like a great opportunity. I went around extolling the virtues of Toilet Bot to all the women in the office. One after another, they all expressed interest in the project until I brought up the possibility of installing it in their restrooms. One or two refusals could be a fluke, but after a few dozen it became clear that the women of the office are simply not interested. It defies explanation, but c’est la vie.

Fast-forwarding to today, Toilet Bot 0.4 lives on, with improvements such as LED indicator lights in the hallway outside the bathroom, allowing passersby who aren’t currently on Slack to stay connected with the latest toilet updates. The men’s room has become a utopian paradise, with the exception of the occasional 30-second line for the urinal. If only there were some way to over-engineer a solution to that problem…

For more information on the technical details of Toilet Bot, visit its GitHub page. Want to work in the kind of environment that encourages you to build a Toilet Bot and then brag about it? Join our team!