• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
  • entries
    437
  • comments
    1000
  • views
    334984

Test-driven: Or, how I saw the light

Sign in to follow this  
Followers 0
evolutional

1125 views

T minus 1 month.

In my current project I'm working with a rare-breed programmer. An SDET, a Software Development Engineer in Test. These guys are accomplished programmers but focus on software quality.

"Hey, I write quality software", I say, "It works, doesn't it?".


T minus 4 years.

Working in a software team for a financial shop. The Head of Software keeps talking about Agile software development, Test-driven development, Continuous Integration etc. Sounds like a plan. Try it. Nice idea, can't see how it works. "I always test my code". I say. I do. Console application which wraps the component, fire in data, breakpoint it, verify outputs. Sorted. Job done.


T minus 3 years 11 months.

Cajoled into writing "Unit Tests". Great, double the amount of code to write, same amount of time = less functionality. Features creep, pressures mount, tests get disabled. Code rot. "I write quality software, it works doesn't it?".


T minus 3 years 9 months.

Epic megafuckton of a bomb drops. Trying to debug, fix, unravel. Breakpoints are my friend. "it works on my machine". Late nights. Slipped deadlines. Break original functionality. QA test team get blame. "Test should have spotted this, it's a basic bloody error!".


T minus 6 weeks.

A leopard doesn't need to change its spots. "I've been coding in OOP systems for years, I know the best practices!"


T minus 7 years.

Massive refactor of game engine. Deeply nested inheritance trees. Ugly! Decide to favour composition.


T minus 5 years.

Massive refactor of game engine. Too many hidden dependencies. This OO-lark is a pain!


T minus 3 weeks.

"We need to ensure high code quality on this, try looking at test driven development or something".

"No, that doesn't work. Tried it, takes too much time and gets in the way".


T minus 2 weeks.

Dependency Injection. Heard of it. Tried it in the past, found it to be useful in some situations. I'll learn that later. No rush.


T minus 7 days.

"This code you've written needs a real Cloud Service deployment!".

"Use dev fabric, it's what it's there for! I've written a load of tests to verify it works!"

"But you still need a hard external dependency!"

"That's life".


T minus 4 days.

Trying to test code which relies on something I have no control over. "I know this can happen, but I have no idea when or what causes it. It's part of Azure, how do I sort this?".


T minus 3 days.

"I need to learn this stuff". Spends long weekend reading, on YouTube and more, practicing, practicing, practicing.



T

The way I write code now is fundamentally different to how I wrote code 7 years ago, 7 months ago, even 7 days ago. I always prided myself on being a half decent software engineer, but ultimately I will confess - the majority of the code I've ever written in my lifetime has been very hard to isolate and test. I've followed best practices as much as possible, but have almost always ended up with hidden dependencies, internal state that's hard to affect or even worse, hard external dependencies.

Having embraced concepts like Dependency Injection, Continuous Integration, Mocking/Faking and Test-driven Development I finally feel like I've added security and confidence around the things I code.

I've tried all this in the past, even blogged about how I didn't get on with it. It's a tough sell. It adds time to development, perhaps even doubles it, but it's worth it.

Using DI and mocks, I can abstract away hard dependencies on external services or libraries and replace them with fakes. I can cause those obscure exceptions and make sure my code handles it. I don't have to wait for a blue moon, I don't have to slay 15 virgin princesses and hope that quantum mechanics favours my outcome today. I can fake the whole thing and force it. I have full control over the environment my code works in. It's like being a god of bits.

What's more, it has fundamentally changed the way I code. It sounds odd, but everything I code now I see the coupling, I see how state migrates between related components. I've done this stuff before, after all it's "good engineering practice", but lets face it - I must have gotten it wrong. Doesn't matter if the odd one slips in there does it?

I realise that to many of you this may be a "well duh". But to me it's a huge swing. A swing in attitude, mindset, approach and style. it's a paradigm shift that required a "click" to happen. I knew all this stuff before, but now I live it. I find it hard to see how I can go back to my old ways.

3
Sign in to follow this  
Followers 0


4 Comments


It's posts like these that make me wish I'd 1) Completed more university education and 2) Worked where I might have access to experienced and quality mentors. Being so comprehensively self-taught, I am well aware of exactly how weak my fu really is. I'm mostly a cowboy in the worst, most ungodly American nuance of the word, and it really shows sometimes. Dependency injection, continuous integration, test-driven... these are all phrases I know, and kind of understand at least on some level, but so often I just look at them as the sort of thing I don't really need or have time to learn, or as something completely irrelevant to my own processes, and I'm aware that the quality of my code has suffered because of it.
0

Share this comment


Link to comment

Agreed with JTippetts, and it would answer questions like "is there anything ORM produces that we don't do already with our hand-written database code?" As in, our clients don't ask for it so it never gets called into question in meetings. I guess cowboy code is usually the stuff of start-ups started by business majors (without a programming education).

0

Share this comment


Link to comment

I started test-driven development not long ago, when I changed languages and started rewriting all of my code. I've never been able to comprehend why I would spend all of this time writing tests that I hate for functionality that works just fine, but heres the thing: I will always hate writing tests, and the functionality doesn't always work just fine. Every now and again, serious bugs slip by due to testing only enough to ensure that it is functional, then adding it to the final product.

 

There were some bugs that I found while rewriting old code that I might never have found if I had gone with the usual "run it until it breaks; if it doesn't break, it's bug-free" method. TDD didn't inherently give me speed of development; the hundreds of tests for a module gave me both a supreme peace of mind, and an instant notification that something was wrong. Though it took me twice as long to write it, I saved more than that in maintenance and bug hunting. Additionally, it helped quell feature-creep in some cases. In order to write tests for all of the functionality before you write it, you have to have at least a little bit of a plan of what functionality you will write. This makes it harder to get half-way through a module, and decide you want to add one more feature to it.

Now, by far, the most expensive use of my time is my new resolution to write documentation for every module as I code it. My headers with documentation are far larger than their implementation source file size, and I spent far more time with that than TDD.

0

Share this comment


Link to comment

Good post for me to read. I see myself in your T - x earlier posts in terms of my current attitude but the programmer I work with is pushing for more TDD approach and I know I need to get over the "twice as much code for no gain" attitude I have. Our particular industry means we can be costing clients a lot of money if we cock up.

 

Good to read someone else's experiences of the attitude shift. I need to grow up and get on this stuff.

0

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now