10 Techniques to writing easy yet stupidly thorough unit tests

Ten Techniques for testing

1. Something In, Something out the most basic test using test box. Give an input, get an output, test. This allows us to test transformations, calculations, formatting and simple decision making. We send in different inputs and verify the output
2. Meticulous Methods This is one of the easiest mocking techniques. We mock the very object we're testing but mock the other methods that should be called. We count if and how many times they are called.
3. Reacting To Returns We add a returns from our mocked methods and test how our method reacts
4. Precise Properties Can we test calls to a component which is a property or has been injected into our component? By creating the mock and setting the property with the mock, we can then test the if/how many times they're called and cusomize the returns
5. Non-Injurious Injections Sometimes we need to test whether a component which we obtain from our DI (i.e. Wirebox) when the component is called with getInstance() this will show how to “swap out” a mocked component into Wirebox so we can test it when it's called from within our code.

   getWirebox().getBinder().unmap( arguments.mapName );
    getWirebox()
    .getBinder()
    .map( arguments.mapName )
    .toValue( arguments.replacement );
   

6. Querulous Queries Our tests are supposed to run without side effects which means we might write the query when we can access the database, make sure we get the correct data and then put the SQL or query into our code. However, how do we check if our SQL doesn't change, our parameters are being set correctly, every param is cf_sql typed, or our criteria are correct? We'll look at running tests based on the component created when we run new query()
   • Querulous QB Queries QB is a forgebox module which allows for creating complex queries in a fluent and dynamic manner by creating an passing around the queryBuilder component. We can then test the values in that component's properties without having to actually run the query.
7. Handling Handlers You might be used to running tests on components but testing handlers is a bit different. We actually need to mock the request object itself which, well, can be hard. However, there are elements built into Coldbox that make this quick easy and allow testing of handlers quite straightforward.
8. Satisfactory Signatures We can make sure a function is RECEIVING the correct data by using datatypes and the required tags. How do we know if our function is SENDING the correct values to whatever function it is calling? Moreover, are there ways that our unit tests can let us know if a signature changes? Using the “callback “ property of mock box to test what our function is sending to another function.
9. Accurate APIS When we're making API Calls from our methods, we need to ensure that we're correctly assembling URIs, using the correct verbs, sending the correct token and so on. This is difficult using the cfhttp method but tools like hyper make it easier. (TO BE VERIFIED ACTUALLY. I FEEL LIKE IT SHOULD BUT IT MIGHT NOT BE AS EASY AS I THINK)
10. Exasperating Endpoints Testing the endpoints of an app is basically testing the entire app. Using tools like postman, curl and so on can