So you need some buzzwords definitions ? You’re a manager after all. I understand.
Ok I’ll give you a brief tour of words that matter.
TDD Test Driven Development
Not really a method but a state of mind. In this approach, after some specifications are around (or sometimes not), the team works first on the tests not on the code. This includes integration tests (define what will be tested in the finished product), but also unit tests.
A developer applying TDD at his atomic level will proceed like that :
- Read specs for a feature he needs to write
- Identify what can be unit tested and what will need integration testing (see next episode to see what can be tested and how)
- Write automated unit tests that fails when executed (because the code is just an empty nutshell).
- Write the code
- Run tests to see what works or not
- Repeat step 4 and 5 until all tests work.
Automated Unit Testing
Any coded test that runs a method or a set of methods and checks the result automatically. It’s like normal code but it’s not part of the final software. Unit test must be atomic enough to be executed many times without changing the state of the all software. It’s generally in the form of a Unit Test class by existing class. And 1 or many test methods by methods to be tested.
A famous framework to build unit tests is JUnit. If you are curious you’ll find plenty of examples of unit tests written in JUnit on the web. Or just ask one of your team member to show you one.
Integration Test
Any test that could not be performed in an automatic and atomic manner. For example : testing methods that access to database, or network. We’ll discuss differences with unit testing in episode 3.
Mocking
Sometimes a tested method calls a set of classes that are not accessible in the test context or not ready yet. The dev will simulate those missing objects. It’s called a stub.
Sometime those objects are available but the test must receive fake values from them. So we mock those objects.
I use Mockito every day. But if you search you’ll find a lot of great libraries out there. Just ask your dev team which one they use.
Contiuous Integration
Continuous integration is a system used to process, build and test constantly and automatically the code developers are producing. A famous system is Jenkins (ex-Hudson). Install it in a server and every time a developer commits some changes it will tell you if he broke something or not.
Even if there is no absolute direct link with our subject, we’ll talk about it in the episode 5.
TODO
- Have a walk in your team. Go to the dev guys and ask them to give you their definitions of those words. This could be a great time exchanging about your view and theirs on software quality.
- Ask your team which frameworks they use.
- Maybe have a look at what it looks like when tests are run. That’s pretty fun to see those lights turning green one after the other. It makes our soft work more tangible.
For the developers out there
Feel free to correct or add your definitions.
Have I skipped some words / notions ?
