Hello! I’m Bandboo’s first intern, Jing Lin. I interned at Bandboo to further my interest and ability in programming as I have always loved coding and playing video games – one of my life goals is to code my own video game. My internship at Bandboo was also my first work experience, so when I came here, I had no idea what to expect. It turned out to be quite challenging but also really cool as I got to build things that I previously thought were extremely complex (I had tried to build them but the attempts were not very successful).

I’ve only been to one office before this, so my impression of offices was basically that they were filled with small cubicles for people to work in. So I was quite surprised when Bandboo’s office had one common table for all of us (4 people). It felt more like group work at school than an office. I didn’t really like the idea of working alone in a cubicle, so this was quite a nice surprise as it felt more open. My most lasting impression of Bandboo was a really good one as I brought in Milo on the first day and when I came in on the second day, the fridge had lots of cans of Milo for me to drink, which made me feel like I was an important part of the team which was really nice.

My first task was to build a automated regression testing framework which we would use to automate testing of our websites before they are released into production, or to populate development databases more efficiently. So naturally, my (and perhaps yours too) first question was – what is a regression test?

Here’s a demo of the first part of the regression test for Bandboo’s main site:

A regression test is a test that is run after changes are made to the code to ensure that the addition of new code and functionality has not interfered with previously implemented functions and caused them to stop working. The test does this by automating the actions humans are likely to input at each website, and if an unexpected result occurs, the test will stop and thus identify where the error is. This also makes it easier to debug errors as we will know exactly where they have appeared. Having a human do this every time the code is updated would be very tedious and boring. Furthermore, humans may miss some test cases and so may not catch certain errors, causing them to go into production and affect users. Maintaining a constant test case repository will prevent this from happening. Thus, it is far more efficient to automate this process.

A sample of the automated regression testing framework can be found here.

This regression test framework utilises Selenium to run a Google Chrome browser (to use other browsers, simply download the browser’s driver and configure accordingly in /util/driver). The main class (SampleTest) consists of various test cases (OpenGoogle, GoogleSearch, Navigate) which are individual Java classes. In each of these test cases, various actions can be input to get the browser to do what you need. Currently, the framework supports opening the browser, changing URLs, entering text, clicking, checking and getting values of web elements, hovering, selecting from dropdown boxes, inputting files and closing the browser. To use these actions, you will need to specify the target web element which can be done by using its xPath – simply right click the element, inspect element and right click on the portion of the code where the element is in and copy->xPath, then simply paste it into the code. Each action also has a pause time input in its function, which specifies how long the browser will wait before executing the command. This is useful when pages take a longer time to load. There is also an in-built “retry” function which can be found in EnterText, Click and some other functions (Driver:32 and Driver:47) where the browser will try to execute the action again after 1 second if it fails the previous time. Developing this framework makes testing fast and easy, and watching the test execute automatically with one click of the button is a lot of fun too.

Previously, I had only done basic automation using AutoHotKey (Windows) and Keyboard Maestro (Mac) to do cheesy things like auto-clicking in idle games, and this experience of doing more large-scale and framework-based automation was very cool. You can make your own test cases using the framework as well, and also have fun experimenting with creating new functions (a simple one would be double-clicking).

Another fun thing I got to do was to utilise the deeplearning4j library to build my own machine learning prototype which learns how statistics are correlated using past data and uses this to predict the future value of one statistic given estimates of the others (for instance predicting future GDP given an estimated prevailing interest rate, fixed capital formation etc). The machine learns using a neural net, which is rather complex stuff. In a simple one-layer neural network, the machine initialises the weights it gives each input variable, and based on how close the predicted and actual results are, adjusts these weights accordingly so that (hopefully) the next prediction will be more accurate. To put it simply, it follows a trial and error model and moves in the direction of lower error until the error is completely minimised, much like how humans do things. (hence the name neural net) Over a large training set, machines can learn to predict the output very accurately (as long as there is actually a correlation between the input and output). There is a wide variety of sample code available for the deeplearning4j library which can be found here for you to play with. Machine learning has seen many developments recently and has many potential applications such as in astronomy, and it was awesome to be able to work with it and actually build something useful with it. It’s also an amazing feeling to be able to build something that can learn on its own.

By far the most challenging tasks I got were those involving the websites that Bandboo runs on. Currently, the regression test project has about 30 files and the machine learning project has about 5, but the combined back-end and front-end of Bandboo comprises over 300 files spread across multiple projects and utilises 5 languages (html, css, java, javascript and SQL). The framework is based on abstractions. Abstractions establish variables that define a type of class – all classes of the same type will extend the same abstract object, so they must follow a certain structure and contain certain variables, but can perform different functions. The concept of abstractions is quite similar to how cells work – cells must all have specific parts such as the nucleus, but can perform different functions based on the purpose of the cell. Abstractions essentially force the programmer to follow certain coding practices such as implementing a validator for each servlet (else the code would fail to compile), ensuring that all servlets are attached to a validator. This acts as a form of quality control that discourages lazy coding and creates a more structured and consistent code once the framework is understood. If it were not for these abstractions, the codes I would have contributed at the start would have been of much lower quality and be difficult to maintain if not well documented. Understanding the entire framework was very challenging as all these files are interlinked and dependent on one another, so it was not practical to learn their roles part-by-part. After building several modules, studying existing codes, making lots of mistakes and spending lots of time debugging, I finally understood how the process works and could build larger and more complex modules.

My experience at Bandboo was definitely cool and very different from my experience just messing around with code and building my own small projects prior to this. And of course, a big shoutout to everyone at Bandboo for making this experience so awesome.