To the un-initiated, it may come as a surprise that software testing is a very controversial topic. People have strong convictions about testing approaches, automation and why theirs is the true path to enlightenment! It’s time to pick your horse, choose your religion and name your first born. As Managing Director of a software company, I’ve got a take on this that I want to share…
Manual Tests
Most projects will have a team of people, whose job it is, to find defects. These are the last line of defence, before a project hits the live server. Treat them nicely and with respect. They’ve got your back after-all !
- All software should 100% be tested by real people.
- It is a good choice for low budget projects working out cheaper than developing the automated options.
- Manual testing does not scale well. Imagine having to run a regression test every 10 minutes. How many testers would you need for that ?
- Skilled testers can be very expensive!
Automation – Unit Tests
By breaking down a project into small isolated chunks, individual functions can be tested with methods of automation. With enough of these units, you can test the entire thing. It’s literally the brute force approach to low level software testing.
- Fast to run.
- Unit tests can be time consuming to write, confusing and nebulous.
- Given the abstract nature of the units, the tests can be utter gibberish at times, with no back reference to the real world.
- They are tightly coupled to the low level implementation. This makes them brittle and prone to breaking at the drop of a hat.
- They can be hard to maintain. Given the overwhelming number and close implementation coupling, you can soon be out of your depth when trying to make the most trivial of changes.
- Since you don’t need to understand the bigger picture, but can still “do your bit” unit tests are often used as a crutch for weaker developers. I’ve seen unit tests become the be-all and end-all of development life, simply because its all they know.
- Unit tests have been around since the 2000’s. They are really old school and made a massive difference when they first came on the scene.
- Since they deal with the low level, they completely miss the bigger picture. So you may have a great set of unit tests, which cover every line of code, but unfortunately the web app doesn’t work, looks terrible and falls over with the changing wind.
- Super expensive, as the overall development effort is massively increased.
- Unit tests do produce well tested, and working code. However the end product will be a bag of spanners, with a tinpot hat, and look like Homer Simpsons car.
Automation – Test driven development
The premise of Test Driven Development (TDD), is that before you put down a single line of code, you write your tests first. You let the tests drive your code.
- This is complete and utter Snake oil! Doesn’t work. Haven’t seen it working, don’t believe anyone that has.
- Lots of companies, when they interview try to “Lord it” by saying we do test first blah blah. Bullshit detector going off the scale! I’m guilty – I once used it for Roman Numerals paired programming test, to give the impression we were way ahead of the curve.
- I’ve seen poor developers use it as a crutch. Loved the enthusiasm, loved the sentiment, but ultimately they had just been taken in by the “Agile” thought leaders, with no practical development experience.
- TDD produces some of the worst abominations I’ve ever seen.
- Just so you are absolutely clear… TDD is NOT real !
Automation – BDD Cypress tests
Cypress is a javascript based testing framework which runs in the browser. Behaviour Driven Development or BDD is the one true religion I follow. It’s the only true Messiah. The rest are false idols. In 20 years of the development industry, its the only paradigm that has ever ticked all the boxes and reliably worked out every time.
For me Behavioural Driven Development is a two phase thing:
Phase 1: Develop the code, get the platform working and make everybody happy. The customer is happy, the developer is happy and the tester is happy. Now that everyone understands how the system works, it’s time to lock in the behaviour using cypress tests. All hands to deck. This shouldn’t take too long, as everything is stable and predicable.
Phase 2: Now that our royal oats have been sewn, we can harvest the free BDD energy, have the goose that laid the golden egg. This is our Jerusalem. We’ve reached the end goal of software development. New features are simply added to the cypress scripts, driving the code changes. The whole software maintenance bit becomes very tactile, visual and trivial.
- Cypress is very easy to work with. It exists in complete isolation to the software under development.
- It’s quick to develop. Even mid size systems, can be scripted up in days.
- As it’s very visual (literally forms filling, buttons clicking) its very easy for everyone to understand.
Integration level testing with Cypress is our “true north”. This is how we role! A strong team with confident developers will have no problems using a BDD Cypress test only strategy. The end product will look amazing, functionally meet the customer needs, and be delivered quicker.
