Skip to main content

Why Test and Mock - dramatized

The following was a sleep induced dialogue about using mocks in testing and that running tests against each function in isolation,even if it uses actual live code in its dependencies.

Q: Why isn't that unit testing?
A: Because Unit Testing when you test one function and only that function.

Q: Isn't that just semantics and an argument used by testing snobs? Who cares as long as the test is seeing if the code works?
A: That might work for simple functions but as soon as your code touches another function you are then testing two functions. So if the code breaks, which function is broken?

Q: You run the tests for the other function. It's like bricks, you build and test the code on the "bottom" of the dependency chain and then work your way up.
A: Do you have a map of all your code and what depends on what at all times? How do you know in what order to run your tests?

Q: Well, once the bottom layer is done, it shouldn't change.
A: Ah, so you never refactor any code once it's written? How do you know if you broke something?

Q: You run the tests for the code higher up.
A: So you DO have a map of all of your code and what depends on what and then an automated system that runs your tests in order of dependency so you know if a change you made broke something....Do you have to run your code against a database?

Q: It's a data driven app, of course we do!
A: Against live data?

Q: We have a copy.
A: Do you have a way of making different permutations of the data you're testing against?

Q: We edit the records in the database or find different accounts that represent what we want to test?
A: So in order to avoid mocking, you've created a system which tracks all dependencies in your app in real time and runs your tests in order of dependency up the chain while keeping a copy of your client database open and editing records so when, you log in through an interface which may or may not exist yet, it gives a different result and then changes the data back quickly before anyone notices and has indexed every possible scenario that will come up and that will run quickly when you have an automated build system?

Comments

Popular posts from this blog

Creating Stories and Tasks in Jira: Personas and our Software Development Team

Part of the CI/CD Development Series The next step is developing who is on our hypothetical development team. Given that it has a React front end and ColdFusion as the Server Side language, I came up with the following personas, all of which have their own needs and considerations for our development environment. I've listed all the jobs that need doing, not the people involved since, even on a small team or a team of one, these "hats" are all worn by someone, even if it's the same person. Personas for our Project Dev Ops Coordinator - The person responsible for smooth and accurate deployments CF Developer - The person responsible for the API and fulfillment code development and maintenance. React Developer - The person responsible for the front end development Database Coordinator - The person responsible for the schema, data, up time and, presumably the testing databases used by the developers. Lead Developer - The person responsible for coordinat...

More on Site Architecture / CI/CD / and Repos

We're starting to move from the high level overview and more into the details of our project.  Architecture We established that we using React as our front end technology and ColdFusion as our server side. At a more granular level, we'll be using React with Redux for our front end app and we want our server side to be not just "ajax" enabled but a true REST API. To this end, we're going to incorporate Coldbox from Ortus Solutions. Repos These two code bases have different needs, and possibly locations, when they are deployed. As a result, we're going to have two repositories: one for the React and another for the API. This will allow us to keep our code separated and cleaner all the way through to deployment.  For each of these repos, we'll follow the procedure we laid out previously with the MASTER branch being used to deploy to production and a DEVELOPMENT branch being used for active work which is then fed into the Master branch via pull requests.  Test...

CF: Scripting amidst the tags

Recently I had to do a quick "utility" page where I needed to see how many files from a directory listing had been recorded into a database. I've been writing about 98% of my CF code in script syntax but, since it was quick and easy, I did this quickly in tags because it was outputting directly to the browser. In doing so, I made an interesting discovery in that, when you use closures, even in tag based pages, you can write cfscript. Here's the example Get the directory listing:  < cfset alljs = directoryList(expandpath( '/src' ), true , "path" , "*.js" )> Get the database listings and convert it to an array < cfquery name = "alljsQ" datasource = "blah" > select * from sitefiles where filename like '%.js%' </ cfquery > < cfset recordedFiles = valuelist(alljsQ.filename).listToArray()> Use a filter function to weed out the files I'd already recorded < cfset missingFiles = alljs.fi...