I mentioned 2 weeks
ago that I was moving
some tests around within our codebase.That work is still happening and will almost certainly continue for
quite some time.
One other task I am
taking simultaneously is quantifying the cost of moving these tests.This ranges from a simple hourly track of my
time to including the time others need to review the code and validating the
tests achieve the same coverage once they have been moved.
I'm also taking a
stab at quantifying how difficult moving a test can potentially be.For instance, a traditional unit test that
happens to be in a less than ideal location is a good candidate for almost a
pure "copy and paste" type of move.Since the test is sharply focused and doesn't have many dependencies, it
is very simple to move around.
Other tests that
start with loading a workbook in order to validate a column is being drawn
correctly (I am making up an example) have many dependencies that have to be
untangled before the test can be moved.This is at best a medium difficulty task and can easily take a large
amount of time depending on how tightly both the test and product code are
For now, I am making
notes on how to untie those knots and moving the tests that are easy to
move.Once I am done with my notes, I
intend to look through them for common patterns, good starting points and use
that data to develop a plan to start untangling the next round of tests.And of course I will share this with others
since I doubt I will have enough time - or energy :) - to do all this myself.
Questions, comments, concerns and criticisms always welcome,
This is a bit of an
unusual week.We have booked the
Washington State Convention Center in downtown Seattle for our annual company
meeting."All Hands" is the
navy phrase that we use to show that the entire company attends - we go over
business strategy, technical planning, development specific tasking, TableauConference planning and so on.
I can't write much
about any of this (maybe not so) obviously.This will be my second such event and I learned a lot of information
last year.Now that I know where to
focus, I expect this year to be even better!
Otherwise, I am
still moving unit tests to better locations.The easy tests to move will likely fill this week for me and then next
week the work gets more challenging.Stay tuned!
concerns and criticisms always welcome,
Last week I spent
identifying and removing dead code.For
what it is worth, the biggest challenge there is proving the code is not
actually used.If you know of a way to
tell if an operator overload is actually called, let me know…
This week I am
focused on moving some of our unit tests to a more proper location.Some of our older tests are part of a large
module that runs tests all across the product.For instance, suppose I want to test Kmeans clustering.As it stands right now, I either have to work
some command line magic to get just those tests to run, or I run that entire
module which tests areas in which I am not interested (like importing from
A better place for
the Kmeans test would be in the same module that holds the Kmeans code.That way, when I run the tests, I focus only
on testing the code in which I am interested and don't need to worry about Excel
importing.There are also some speed
benefits when building the test code.Right now, the old project has references all over the product.It has to have those wide ranging references
since it has such a wide variety of tests in it.That means a lot of file copying and such
during compile time.
One of the other
benefits I expect to see when done is that the time to build that older test
file will shrink because I am removing code from it.As I move the code to the correct module, I
am updating all the references it used to minimize the amount of references
needed to build.So my module build time
will go up, but not as much as the time saved from the older test pass.
There is one final
benefit to all of this.When I build my
module now, I build both that module and the older test code.This is necessary since I need the testing
provided there in order to test any changes being made in my module.Once I am done with this task, I will only
need to build my module in order to test it since all the tests will be part of
the module.I will no longer have to
"pay the price" ofbuilding
that older test project.
concerns and criticisms always welcome,