Sprint 6: The End
Hello everyone. It’s the 6th blog and this will be the last one in the series.
At last we reached the final sprint, and I wouldn’t be touching this project ever again in the future. I can’t say I’m proud of the result, but it wasn’t a pointless journey.
After going through the development phase, I have a lot to criticize about our team, but I find it hard to do so since I myself have a lot to be criticized for. I can’t say I was doing it at full potential, due to internal motivations and external influences. There were times where I was regretting my decisions, and there were other times where I find myself constantly making excuses for the lack of progress in my end. Maybe under different circumstances I’d perform better, but then again, that’s just me making another excuse.
Despite having lots of stuff to criticize for about our team, the opposite can also be said. Our team has a lot to be praised for, albeit not so perfectly. Our team didn’t break, and kept on working hard til the end despite all the problems we faced. Without the team’s tenacity, we would never go so far in development, even if some features were missing.
There are lots of things I learned from all of this, my part itself not included, since I’ve done back-end programming before we started on this project. I was referring to the interactions between various roles, Dev-Ops related work and the amazing capabilities of my teammates.
I would definitely not want to go back to developing for this project, but I certainly would miss it. All the interactions between us serve as a memory of us working in development hell, albeit without the real-world consequences of an actual software developer (although not passing is most definitely a real-world consequence 😢).
So this is the end. As I mentioned before, I will definitely miss all of this. But everything I experienced from this won’t be in vain, as I’m certain of the fact that this will help me in whatever it is I will be doing in the future.
My name is Degoldie Sonny, a back-end programmer of Slovneek, and my work here is done.
Or so you think, ha! We can’t leave without me explaining to you what I’ve learned from this sprint. (hahah)
Mocking: Mimicry, not Mockery
Mocking is an essential tool for testing, especially when the functions are dependent to a lot of other functions. When this happens, you wouldn’t want them to influence the actual function you’re testing.
Mocking is the act of simulating functions or classes to behave however you want them to behave. It creates an isolated environment in which you want the functions being tested to face against.
With this, we can control how we want our functions tested. For example, let’s say there are two functions A and B, and function A is dependent towards function B. In other words, function A relies on what function B outputs. Now, let’s asssume we want to test when function B returns an error; for example, an error where the given parameter already exists in the database.
There are two ways we can approach this. The first way is to make sure that the data with the given parameter already exists in the database. This will require a bit of preprocessing, which in most cases will need to depend on a whole other set of functions. This will result in the testing of a single function requiring a lot of functions, which might result in an error outside of said function. Aside from that, the preprocessing might significantly slow down the testing. Even if that’s not the case, piling it up between lots of tests would still result in a significant amount of extra time wasted.
The other way is to use mocking. Instead of creating a new data to trigger the error, we would just mock the function B. We can make it so that the mocked function B would return the error no matter what parameters we give it. This way, regardless of what function A passes to function B, function A would have to handle the error given from function B.
Stress Testing: Intentionally Giving Stress, How Cruel
Stress testing is another type of testing our software. Unlike functional tests, which are based on logic and expected outcomes, stress testing tests the software under extreme conditions. Usually these extreme conditions refer to high load, but it’s a general concept which can apply to other conditions.
The aim of stress testing is to measure the performance and behavior of our software when faced with said extreme conditions. This will serve as a benchmark for future development use.
Our team did stress testing towards the back-end server a few sprints back, and the results are as can be seen below:
No problems were found as it all passed in 13000 milliseconds.
We also did stress testing towards the front-end server:
Likewise, the front-end server didn’t find any trouble rendering each of the data.
Profiling: Optimizing Code
Profiling is the act of measuring various aspects of the code while running it. These aspects include (but not limited to):
- Time complexity
- Space complexity
- Function call frequency
The information gained from profiling is commonly used to optimize code, which directly influences the efficiency of running our code. Problems arise when our code isn’t well-optimized, such as unresponsiveness, memory leak, useless program space, etc.
There usually are profiling tools to help profiling code. These tools do the measurement for us as we try to optimize the code, since we usually would need more time spent thinking on how to optimize the code instead of thinking on how to do profiling. Aside from that, there are a lot of trials and errors involved in optimizing code, so the extra speed from using profiling tools would significantly help.
Since most of our development time was dedicated to implementing features and fixing problems, we didn’t have any concrete use of profiling tools and we also didn’t do any optimizing towards our code.
This is it, the actual end. I’ve said my good byes up above so peace out ✌️.
