Test-Driven Development
Who hasn’t heard of it? The concept of code to pass the tests and only the tests and not the other way around. In other words, it’s simply a safety guard. Nothing can fail if nothing new has been tested, yadda yadda. Ok, so what’s new? Nothing really, except my experience working with TDD in my PPL course, which I would love to share.
How does it affect group work
Nothing worse than encountering bugs and errors from lines of code that are not committed by yourself. The implication is that you have to spend extra time debugging someone else's work, just because your work happens to be dependent on theirs. How to avoid it? Write meaningful tests, and shoot for 100% coverage every time.
Frontend TDD: Functional Positive-negative
Now, frontend testing differs quite a bit from backend testing. Whereas backend tests individual unit functions to work properly, frontend guys test overall functional components. This means testing is done on a series of flow of events, rather than on a singular event/function call.
Take a look at these test examples for the TBCare login page. The main flow is the user enters username and password fields, and then pressed the submit button. If the password is longer than 8 characters, then the login request is submitted (this is because on signup, the user candidate is required into having at least 8 characters of password). But, if the password entered is less than 8 characters, the validator will trigger an error modal, canceling the login request.
These types of functional tests are called positive and negative test-cases, where we test both the success and fail events of a business flow.
Fix mistakes, clean the codes, by not changing the functionalities!
Yes, you know what refactoring is. It is important to note that refactoring does not equal to fixing bugs. Because you won’t be having any bugs if you follow the standard and proper TDD rules. Rather write more tests and implement correctly based on the new test if something were to go wrong.
Happy testing. Cheers!
Written as an assignment for my software engineering project individual review.
