Skip to main content

The DevOps Handbook, the Testing Pyramid, and Unit Testing

We are reading the DevOps Handbook at work, and today we discussed chapter 10 -- the testing chapter.  I was really excited to see that even in DevOps land, people recognize that more and faster running tests are better.  There were many references to google's testing transformation in the book for those that wanted a strong reference for why automated testing is so important.

I really appreciated that the book referenced the Testing Pyramid and discussed the importance of focusing mainly on large numbers of unit tests instead of large numbers of slower integration/acceptance/ui/etc kinds of tests.  The Testing Pyramid really encourages a large unit test suite as the base of the pyramid as well-written tests.  I agree with this mindset; a large suite of unit tests encourages the coder to really think about the coder's public APIs and how they might be consumed.  Even if the API lives within the same code base as it's consumer because the consumer is just another class, one never knows how long code will live or how many people will come afterward, trying to understand the intention of a class.  A strong test suite expresses the desired uses of an API really well, and many even argue that tests serve as strong documentation.

The thing that bothers me about all of this is that in spite of experts and literature preaching about how important unit tests are, so many developers do not understand unit testing tools, what a good unit test looks like, or why unit tests are desirable or important over other kinds of tests.  Many developers likely think about testing at higher levels of code because these tests more closely resemble desired functionality for the user.  This is a great place to start, granted, but there is so much more to testing.  Tests are great for helping the developer think about the unexpected.  They're also great for helping the developer clean up an API as they realize through the test that certain parameters need to be more cleanly expressed.

I wish I had been taught more about unit testing when I was in school.  Do schools focus on these things much nowadays?  I last took formal coding classes around 2007/2008, so it has definitely been a while for me.  I feel like junit and mockito are the crux of my development kit, and last I checked, these are still very highly used and relevant tools, so at least I'm not falling behind on that front!

I also got to show off one of IntelliJ's testing features to my teammates, which is the built-in code coverage (read: line coverage) tool.  It is always a good day when I get to talk about testing and tools I use for testing.
Labels:

Comments

Post a Comment

Popular posts from this blog

JHipster, Liquibase, MySQL, and initializing data, including booleans!

When generating a data model from JHipster JDL, we will often declare entities with Boolean fields.  I have so far abandoned H2 as a database because of liquibase issues, and both my dev and production databases will be MySQL.  This is relevant to the Boolean field desire there is a long history in software development of how to store Boolean data types in a SQL database whose standards classically do not support Boolean. In the current JHipster/Liquibase incarnation, tables in MySQL are generated for us, which is really nice.  The Boolean data types are stored as BIT  (1).  This is not a problem so far -- most developers seem to agree now that as a best practice, we should store values in databases as false = 0 and true = 1, and a BIT(1) is a great, simple way to do that. An issue arises when we try to use liquibase to set/update our database to the desired starting state.  For my project, I've chosen gradle instead of maven as a build tool, and gradle has a plugin for liquiba
Post a Comment
Read more

Spring Security - Authority vs Role

I have spent a lot of time recently trying to understand the difference between Authority and Role in Spring Security.  This is a brief review of what I found. When creating a UserDetailsService or overriding configure(AuthenticationManagerBuilder auth) in the security config class that extends WebSecurityConfigurerAdapter, I basically get complete control over what I populate inside of the UserDetails that is used/returned.  This is important because the UserDetails interface really only cares about how to return one thing: Collection<? extends GrantedAuthority> getAuthorities(); A GrantedAuthority just seems like a glorified String wrapper that names some thing.  The question is... what is that thing? This is where the subtle difference between Authority and Role comes into play. I think that Role is an older thought/construct that automatically gets plugged into Authority if we just create a user with a Role.  But completely forget about the code and classes for a mi
Post a Comment
Read more

Gmail internal application, Two-Legged OAuth2, Server to Server authentication, and Google API versions

I am working on a little tool at home in my free time to put some skills into practice.  The general idea (nothing novel) is this: I have some financial alerts sent to a new email address I have spun up on my domain.  I am creating an AWS Lambda that will wake up on an hourly schedule, read those emails, and publish SNS messages with parsed financial transaction information.  I then will have an SQS queue listen to the SNS message topic that is consumed by a Step Function.  The Step Function will: store the financial transaction information into a database send an SMS to me if the transaction is above a certain threshold. I could later extend this to do some aggregation reporting, etc if I wanted, too.  This will only work for my own financial transactions, and the data being gathered/stored will be sufficiently vague, so I am not really concerned about financial security for this project. The biggest hurdle I have run into so far is connecting to Gmail securely.  I was ab
Post a Comment
Read more