Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!
Great, then we're both happy. We don't want some arrogant know-it-all who thinks he's above doing a simple technical test to prove he can do the thing he's being contracted to do.
Join me for a tour of the IT department of any bank in the city and we'll play a game of "observe the working practises of each developer and try to tell apart the permies from the contractors."
I know a lot of you like to think you're special and a cut above the permies, but in reality you're...
There's a lot of contractors with long stints who I'm sure could explain their previous roles and what they delivered fairly confidently, but that doesn't tell us whether their code quality is any good. Case in point, they might talk about unit tests, but can they write any when asked to do so...
When done properly, tech tests are a great way of filtering out poor candidates.
The numbers of candidates we've seen who have years of experience and yet can't follow a simple spec that requires ~15 lines of straight forward code and a couple of unit tests.
Which is fine for testing a few input/output cases but you'll never achieve the same level of granularity that unit testing allows for, nor will you be able to verify how exactly your classes are interacting together.
Simple example - We take our Calculator class and add component B to provide...
Sounds like the problem here with the team (as with a lot of the industry) is a complete lack of common sense.
An over-engineered system such as the one you describe will only be made worse by the addition of DI.
A properly designed one will only benefit.
TDD and Unit Testing are not the same thing, and doing one doesn't mean you can't do the other.
Agreed that in some cases, where there is a natural coupling between classes, that it makes sense to test the classes together (the classic example would be the CalculatorInputParser and...
Read through some of the blog posts. Sounds like the general idea is to have a BaseCommand which is actually just a big ballbag of mutable dependencies, which are all (hopefully) set prior to execution, with each command implementation able to access any of them.
A complete antipattern and a...
Interesting idea but I see a few potential problems:
-Consumers are still tightly coupled with commands the they rely on
-Consumers still need to construct each command (including supplying of dependencies). If those dependencies also have dependencies then your code will get messy very...