DEV Community: Rishi Baldawa

Understanding Systems Through Tests

Rishi Baldawa — Mon, 16 Apr 2018 05:00:00 +0000

I'm assuming the reader has knowledge of differnt tests. If not, consider skimming through this blog post or wikipedia.

When I'm in a strange codebase¹ and short on time, I've taken shortcuts by going through all the tests first. If the tests are well organized, plentiful and easy to comprehend; I can swiftly understand the verified rules and restrictions of the system (or set of systems) and its neighbours. If they're sparse, messy or in dire need of help, I know my week got way more interesting.

Unit tests

Reading unit tests should help you realize what the team thinks of as a single piece of unit. The input, output values help you guess what kind of data flows around. Mocks / Stubs should aid in figuring out how other components behave. The test names should help you figure out the use-cases / edge-cases around the component. Tests around specific dimensions related edge-cases (like dates, country) tell you that the system, and any changes you make within it, needs to be respectful of them.

Lack of tests or obvious gaps, implies the codebase has not been fully verified. You're in the wild wild west now, boy!

Integration Tests

Integration tests help you figure out the boundaries of the system and services that we interact with. The input / output values help you understand the kind of data being shared between systems. Compared to unit tests, this should help you identify which data stays within the system and what gets passed around.

If there's too many integration tests (esp over unit tests), expect the system to not care as much about latency (maybe even performance in general). It is possible that the system cares a lot more about availability or accurate interactions. If there's too many tests against a particular neighboring systems, I'd bet that service is flaky and, in past, developers have had bad experiences working with such systems. I would watchout for them as well.

If there's too few tests, either the system doesn't have as many interactions or the integration with neighboring systems hasn't been painful yet. It is generally a matter of time. Either the software get deprecated or someone adds the tests after a frustrating outage.

Acceptance Tests

Acceptance tests, when available, are a good way to understand the core functionality that the software supports. There's still a bit of code to business logic translation but is always an useful exercise. I don't focus too much on the inputs and outputs as these tests tend to have a bias towards the "happy path" use-cases. Any odd edge-case handling is probably present to counter the non-deterministic behaviour.

Feature Tests

Generally what the non-programmers wished the code would do. If there's too many of these tests, a QA or Developer went to the town with BDD. Either way, it'll make an honest attempt to deliver the same value as an acceptance tests but with more humane language.

From experience, there's very few accurate feature tests. Most express partial functionality or worse. The code executing the test spec could divulge more information but I've been burned few times in the past.

Comparison Tests

This tells me the code Extracts, Transforms and/or Loads critical datasets and the system needs to focus on accuracy. Also, as the cost of comparing the data is smaller than actually translating into POJOs, you may be dealing with a complicated structure or a very simple one; but nothing that sits in the middle. There may be compliance / regulations involved as well. One big takeaway would be that if you are adding new sources or changing the output, ensuring that the tests are still accurate will be painful the first time. Probably a manual effort.

Generative Tests

These are so rare. When they are present, they help me get a quick grasp of the core assumptions and expectations of the system. The variants help me realize the terminologies / technologies the system deals with. If these are hard to understand then you're dealing with a complex system with many side-effects².

Fuzz Tests

These tell me that the system is expected to take care of all error handling and should not crash. All apis need to be conscious of random inputs³ and insecure behavior cannot tolerated.

Side Notes

If the tests are not part of the deployment chain or aren't carried out on a frequent basis, you can bet they are out-of-date. Don't bother with them and just move on. At the very least, tread with care.
There's way more types of tests. Even the ones I described have sub-categories. I picked the ones I come across frequent enough to form opinions.
This is partially written during a particularly busy period. I ended up taking many gaps and days to complete this. I apologize for any inaccuracies, in advance.

I was leading a ranger team for more than 2 years so this happened a lot. ↩
Probably justifies the need for Invariant testing ↩
Property-based testing helps me know the reduced subset of valid input values that can be passed in. ↩

Fixing Corrupt ZSH History

Rishi Baldawa — Sat, 07 Apr 2018 05:00:00 +0000

Today, when I logged into my console, I saw following error message

zsh: corrupt history file /home/rishi/.zsh_history

doing a quick search, I was able to reach a stackoverflow link¹ that recommended I run following set of commands

mv .zsh_history .zsh_history_bad
strings .zsh_history_bad > .zsh_history
fc -R .zsh_history

I ran them and everything was handy-dandy again. This did made me wonder what these commands do.

Rename

mv .zsh_history .zsh_history_bad

Well mv should be familiar to anyone who's toyed with linux. It moves files from one path to another. Also often used as a cheap was to rename files as we did here. More details on move in the man page.

Sanitize

strings .zsh_history_bad > .zsh_history

Strings is interesting. I had not come upon it before. Based on the man page:

... strings prints the printable character sequences that are at least 4 characters long (or the number given with the options below) and are followed by an unprintable character...

It seems strings is a nice way to actually get the printable characters in a file. In our case, this means if the .zsh_history was corrupted due to non-printable characters², this will help parse them out. It also means if you ran any commands with non-printable characters, you've now lost them from your history as well. I'm very unlikely to run printable characters, so this wasn't as big of an issue but this may make past commands for QAs and pen-testers a tad-annoying.

Parse

fc -R .zsh_history

fc was interesting. It doesn't show up in the manpage. I ended up in a searching a fair amount to realize that this is a zsh-built in feature. There's some information about it within zsh documentation.

...'fc -R’ reads the history from the given file

It seems fc will interact with your zsh_history. In this case, we are reading from the file and, since no second file was mentioned, putting it back into the same history file. i.e. re-writing history by parsing the same file.

Cleanup

rm .zsh_history_bad

This wasn't part of the original script but you should always clean-up after yourself. This command deletes the tmp "bad" file that you created in the first step.

Conclusion

If I power shutdown my VM / linux box while zsh is still writing content, I can still corrupt the zsh_history. As long as I don't care about any other non-printable characters in the past and open to keep using zsh, I can run the above commands to get back to a happier stage

Technically not stackoverflow but I hope you know what I mean. ↩
Probably because I did a power shutdown while carrying out a load test on a tiny VM. ↩

Virtual Environments in Python

Rishi Baldawa — Sun, 07 Jan 2018 06:00:00 +0000

I’ve been struggling a lot with understanding how to package python scripts & libraries. Some of the tool I use heavily rely on older version of the language. Some even rely on specific version of the older libraries. Working daily at a Java shop, this isn’t all that surprising. The bit that really caught me off-guard was how to make it all work when there’s different libraries to work with. e.g. some libraries require Python 2.7 while one of my other projects requires Python 3.4 or above. It seems the solution is to use VirtualEnv.

VirtualEnv allows you to isolate different packages & even python versions. You need to manually activate / deactivate a virtualenv but once you are in one of these, each virtualenv can have its own copy of the Python and dependencies in the site-packages directory. This allows you to create multiple environments within the same devlopment box / laptop. Typically, you create one virtual env for each workspace / project but you can just as create multiple envs for the same project to see how your library works in different situations. It’s a pretty sweet deal.

Installation

To set it all up, followthe installation guide

sudo pip install virtualenv

To create an new virtualenv you basically go to your project & activate

cd my_project_root_folder
virtualenv -p /usr/bin/python2.7 my_project
# now you activate
source my_project/bin/activate
# now do your dirty work like...
pip install -r requirements.txt
# when yo done, deactivate
deactivate

More Resources

Some links that really help me understand how packaging works in python

Application Dependencies - overview of python dependencies
Alice in Python projectland - takes you through how packaging works at a very simplified level from a simple script to a fully fleged application / library
setup.py for Humans - sample project explain the different values within setup.py & the moar relevant resources
setup.py vs requirements.txt - differentiates between setup.py & requirements.txt and explains why both are required.
Hitchiker’s Guide To VirtualEnv

Misc links I found on the way

A template to make good README.md

Note

You have to always manually activate / deactivate your virutalenv. This makes you prone to human errors if you are not paying attention. There’s tool to automate this step as well but I’ve found them to not work as well (so far…)

Another issue I’ve faced so far is inability to isolate dependencies into their own shell. Something along the lines of JarJar. I’m not convinced this is a bad thing but it’s still a minor annoyance I need to work around with (by creating a project / microserver).