Skip to main content

To Unit Test or Not to Unit Test

There are so many ways to test software.  There are so many ways to organize software tests.  And there are so many opinions on which way is best... that it becomes difficult to decide on a path.

I recently presented a short bit on mockito.  The focus of the presentation was on how mockito works.  In the middle of the presentation, someone asked "I understand what we are talking about...but is this even the right way to test?  Is this a good idea?"  Fundamentally, the person was questioning whether unit testing itself is a good idea. 

In a previous post, I mentioned the test pyramid and unit tests, so it shouldn't surprise anyone that I believe in unit tests.  When this happened in the presentation, I was genuinely shocked to hear someone bring up an argument against unit tests.  That led me to start googling a bit for such things... and behold, there are a fair number of people out there who are against unit testing because they want to see more integration/system testing automation.

I understand the arguments.  I understand why people get frustrated with unit tests making code feel brittle because changing code breaks a test, even if functional requirements are still working.  I understand why people think this wastes time.  What I don't understand... is how people are able to get sufficient test coverage from test suites that run at an integration or system level that can:

  • run reliably (often, some piece of a system is not working in dev/test environments... and so tests fail)
  • truly run the code's state/life cycle without hacking it (doesn't hacking it kinda defeat the point of a test?)
  • complete in a small amount of time so that I can use those tests as an active part of iterative development
  • not rely on a whole separate test framework/code-base that is often more complex than the code base being tested
  • ensure internal public APIs are rock-solid for later consumers who stumble onto them without background knowledge.  (Many higher level tests do not adequately cover the input space of all public APIs internal to a code base.)
  • work when insufficient infrastructure exists to test code outside of production at a system level.  (This sounds horrifying, yet seems to happen over and over again.  Any reliance on a 3rd party system/API often immediately causes this to happen.)
I can go on, but that is my first set of major concerns when considering abandonment of unit tests.  For me, these problems seem more important than the frustrations of brittleness and required extra time for development.
Labels:

Comments

Post a Comment

Popular posts from this blog

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 a...
Post a Comment
Read more

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...
Post a Comment
Read more

SQL, Booleans, JPA, and Hibernate

For a long time, SQL and Booleans have not gotten along.  Standards for SQL never really addressed the need for boolean data -- it was assumed that some other data type could easily just step in and address this need.  The result was a lot of different data models for boolean values.  Here are some examples. TRUE or FALSE T or F Y or N 1 or 0 <any value> vs NULL The internet shows the debate has gone on , even as SQL standards have changed .  Coming from a professional background with Oracle, I struggled with this across my teams because everyone had a different opinion, which led to a lot of time wasted due to debate. This said, I appreciate working with native queries in hibernate's JPA implementation against MySQL.  MySQL supports a BIT data type I recently discussed .  When we represent data in MySQL with BIT and restrict the length to just 1 (ie 1 bit), Hibernate JPA magically knows to query and return this data as a Boolean in the ...
Post a Comment
Read more