I have been working on a tiny, lightweight automated testing framework that can be used to test both Linux and Windows environments, applications, etc. I have got a portion of it to a working state and it’s helping me get some Hyper-V automation done. The basic idea behind the framework is to use PowerShell on Windows and SSH on Linux to get things done. And yes, it’s built using Python 3. Anyways, the focus of this post is not the framework but JSON and why I chose it.

I needed a way to pass test suites to test controllers, run those tests, gather results, and then get the results. Since XML is used quite often for passing data between components, initially I thought of using it. There were two main objectives I had in mind: easy for humans to read/write test suites and easy for programmers to read/write XML in the framework. But as I tried to comprehend the scale of the project, XML fell short.

Reading and writing XML is pretty easy for humans but it can be cumbersome. XML allows a lot of freedom and flexibility in how you want to design your schema but it’s too verbose to quickly write stuff. Reading and writing XML using Python, although not too difficult, was not something I had a lot of time to tinker with. Plus I couldn’t get my head wrapped around DOM, etc.

JSON, on the other hand, looked a lot like using list and dict in Python. So I gave it a try and came to love it. The biggest benefit for me was that I had no translation to do between Python and XML. A list of dicts in Python looks almost exactly the same as a list of dicts in JSON. So while I’m writing JSON, it’s no different than when I write Python code. This got me up and running very quickly.

The Python 3 JSON library took a couple days for me to play around with and see how it would all fit in. I tried natural Python to JSON and back, and also reading JSON from file and writing it to file, etc. In the end, it was all very simple.

By formatting JSON and just looking at it one can also see how easy debugging is. The verbosity of XML can make it difficult to quickly pinpoint where the problem lies. Yes, parsers can point out syntax mistakes but semantic errors are easier (at least for me) to see in JSON. However, it has also been the case that I made less mistakes writing JSON than I do when writing XML. So this requires even less debugging. JSON is very neat to look at, when formatted properly.

Of course, for people already familiar with reading and writing XML, JSON might be a big jump. But I feel that with the simple rules JSON has, it won’t be long before any XML-trained user can be trained to use JSON.

To conclude, the biggest reasons for me to choose JSON were its easy reading, writing, and debugging capabilities. I don’t have to switch context between Python and XML and can simply stay in Python mode even when dealing with JSON. If you are starting a new project give JSON a try. I’m sure it’ll impress you. But don’t try to shoehorn JSON when XML would be the better choice (or vice versa). The right tool for the right job.


Comments are closed.

%d bloggers like this: