Test-driven development ensures our project satisfies some requirements set by our product owner. “Why some requirements?”, you might ask — it is because TDD often emphasizes on the functional requirements. Non-functional requirements — like stability of a system — will need to be tested separately, often using external tools separate from the project’s framework. In this post I’ll explore on how to the stability of iur project using Load Impact’s k6 stress tester.
After my RbCAW-related tasks are (mostly) done on the last sprint, my current responsibility as a back-back-end developer is to implement caching so hopefully our homepage will load in less than half a minute
crosses finger. Unfortunately, testing the caching mechanism is a pain in the back.
Fast, isolated/independent, repeatable, self-validating and thorough/timely. Those are the F.I.R.S.T princliples of proper software testing. But, those criterias might not be achievable because of the nature of the tested code. What could we do to achieve those principles? Fool the tests. Continue reading “Fooling Your Own Tests”
You would think a software development platform used by 200+ organizations would have proper and comprehensive documentation about their API. Unfortunately, Phabricator begs to differ. And that’s the polar opposite of good.
Encapsulation is one of the fundamental concept in Object-Oriented Programming (OOP). It hides implementation details of a class, which from outside view are not important at all. Rather than doing everything from scratch, encapsulation provides (relatively) simple endpoints for use by external classes.
Our group’s project, “Phrogress”, collects projects data from Phabricator and summarize it into visual statistics like graphs and charts. This demands an automated method of fetching Phabricator’s data, which made feasible by Phabricator’s HTTP API, Conduit. Simple HTTP POST request to one of Conduit’s endpoints is all we need to fetch information in reasonable JSON format. Continue reading “Our Own Playground”