Hello World: Software Development

I have worked on two large projects now that both had grown large and complex testing frameworks.  When I work on projects, I like to see strong test suites; they help me feel more confident that any changes I make to the code base won't cause regressions/bugs.  This is important because in many legacy code bases, features become tangled and disorganized due to deadlines and scope creep.  We've all been there, so we know how such things come to be. At first glance, the test suites looked pretty good.  Coverage was not documented well, but I could tell that the tests did a good job at covering most important cases and a lot of edge cases.  As I started to dig into the test suites, however, I noticed both projects had a common problem -- the complexity of the test suite grew in a different direction than the intention of application it was meant to test.  I get frustrated when this happens because such suites leave me confused about things like the true lif...

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...

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 ano...

Not long after I discovered IntelliJ IDEA groovy inspection issues in my last post regarding result data tables, I discovered interaction-based testing  groovy inspection issues, too.  This time, interaction expectations like this have inspection problems: 1 * mock.someMethod(argument) This time, I had to disabled the groovy "Incompatible type assignments" inspection because spock's syntax confused the IDE. Spock seems interesting from an expressive standpoint, but it comes at the cost of static inspections.  Given groovy's history of loose typing and the like, I am not too surprised by this information.  I am a huge fan of mockito historically.  I am trying Spock out now, but I'm not sure I am a fan.

When writing a data driven table test in Spock  where my result is a simple boolean true or false, I discovered that IntelliJ IDEA runs an inspection and decides that the code can be simplified by simply removing the result value.  This means it wants to take a result data table that looks like this: where:  checkpoint   || result  "2018-10-22" || false  And make it look like this: where:  checkpoint   || result  "2018-10-22" ||  After allowing this inspection to make a change,  the test will no longer run.  IntelliJ offers the option to ignore this inspection at the method or class level with an annotation: @SuppressWarnings("GroovyPointlessBoolean") Unfortunately, this solution also causes the code to not compile. The only solution seems to be to either ignore the warning and let the little yellow box remain yellow or to disable this inspection entirely within IntelliJ IDEA.  I chose th...