Omar Sharaki wrote:Is a Unit Test for a component(say a method) to be carried out as soon as the component is implemented? Or should I wait for a whole class to be implemented before running test cases for it's components?
Omar Sharaki wrote:Thanks for the insights guys. It's not the first time I've heard the benefits of TDD being mentioned. However, given lack of time, in depth specification and most of all experience I think TDD isn't really an option for us.
After speaking with our chief programmer, I decided that unit tests will be carried out for a class's components whenever a developer pushes his version on to the server. The test results will then be returned to the developer who upon failure of the tests will make the proper adjustments and give the new version in to be re-tested. Does that sound sensible? Furthermore, I'm wondering how often I should get the developers to make reviews of their code. An idea would be once right before each release. This includes releases which happen after adjustment of the code in case of a failed test.
Junilu Lacar wrote:Also, when you tell developers to write/run unit tests AFTER they have written code, the tests tend to be written with a bias to make them pass. This is diametrically opposite of the bias that's needed to write good, meaningful tests. Sorry if I keep jumping to TDD even when you asked to focus on unit testing but to me the two are very tightly bound together in a good development process. Writing the tests with the goal of seeing them fail first sets your mind in the right bias perspective. It makes you think "How can I write this test so that it fails if something is wrong with the code?"
With after-the-fact testing, developers often just want to get this "requirement from management" over and done with so they can move on to their next programming task. So, their mindset is, "How can I write this test so that it passes and I can move on to the other things I need to do?"
Junilu Lacar wrote:Imagine how many problems in your design you can head off early by reviewing the code every 5-10 minutes
Junilu Lacar wrote:Giovanni, sorry for the late response, I just noticed this.
I don't know if you got it, too, but "Working Effectively with Legacy Code" by Michael Feathers is the most important book you'll have within reach when attempting to refactor legacy code, which the book defines as "any code that has no unit tests," including code that you may have written just a few seconds ago.
Another symptom of code that is too tightly coupled are tests that break when the design is refactored. Ideally, tests should be dependent on the production code's API, not its internals. Mocking has a tendency to tie you in to the internal implementation. In that sense, excessive mocking can itself be a code smell. However, mock objects can play an essential role in trying to tease apart and loosen a dependency. They can act as a "shim" or wedge between two tightly coupled classes that you want to make less so. You just have to expect to have a few breaking tests to fix every time you drive the wedge in deeper and separate the two dependent classes further.
So, in refactoring a big ball of mud, you need to prepare yourself to expect things to get worse before they get better. Be careful about excessive mocking and especially watch out for mocks that know too much about the internal workings of a method. Prefer using mocks to simulate interactions at the class API level.
Hope this helps.
Omar Sharaki wrote:Hi all,
I'm the test manager on my university project where we're developing a small software product in Java. I'm currently in the middle of writing up a test document where I'm detailing our test strategy and so on.
My big question right now, however, is WHEN. When are test supposed to be run? We're not doing TDD. This means tests need to be written as soon as there has been some code written. If we take Unit Tests as an example, how often should the tests be carried out? Is a Unit Test for a component(say a method) to be carried out as soon as the component is implemented? Or should I wait for a whole class to be implemented before running test cases for it's components? I'd also be curious to know how this applies to integration tests. However, for simplicity's sake let's focus on Unit Tests for now.
Looking forward to hearing your answers!
Anton Golovin wrote:
There are tools on code coverage that you should look into, they will tell you how much of your code is covered by unit testing. Some code is more important than other code, too, so it needs to be covered mandatorily.
Best to write a unit test around the time a method is written (or even before if possible).
Set up a continuous integration server with your source control and have it run the unit tests on every check in and alert you via email if a run fails.