Priest Game Issues?

[Jens Namtrah]

Yes, but all the OTHER bugs would be caught if you started doing these things.

In the meantime, you build what you are going to need down the road the catch the more complicated issues. Unit testing doesn't catch all issues, but it makes you start writing testable code, which you need for everything else.

Unit testing will save you time once you set it up.

http://blogs.msmvps.com/deborahk/i-don-t-have-time-for-unit-testing/

[Antonine]

Miskel, the devs are saying that they do not have the time it takes to implement unit testing and, given that I've just been looking at the preaching code, I can say firsthand that it would be useless in this situation anyway as it relies on multiple cumulative interactions of players over weeks and months to test how it works in practice - the issue here isn't a bug in the code, it's a balancing issue.

However, you seem to think that unit testing could easily be implemented and should be implemented and that everyone who does any development work on the game is wrong. Fair enough.

But if that's your opinion then I suggest you either put up or shut up. It's already been suggested that if you're that keen on this you volunteer to join the dev team and actually implement it. Believe me, if you're right and it can be done that easily then everyone concerned would be overjoyed by you being proved right. But unless you're actually prepared to step up and practice what you preach it might be a good idea if you stop telling people with actual experience of the database that they're wrong.

Delvin, if you're reading this, I'm away from home today but I hope to start coming up with fixes/suggestions for the preaching/religion spread issue tonight.

[Vita`]

TDD is not Unit Testing; at this point, most of your code is written and needs Unit Testing as you "fix and tweak" to help avoid breaking  things as you fix, and confirming that what you intended is what will actually occur.

Nowhere did I say TDD was unit-testing. But unless you have a magical wand of 'instant unit-testing', I think TDD is the best development practice for implementing unit-testing gradually rather than attempt to do something akin to the doctrinification, where features were put on freeze to convert the codebase (mostly).

[Vita`]

I do agree that learning unit testing is valuable, but as Anaris well knows, convincing one's non-technical bosses of the merits of various development practices is a sisyphean task.

I don't believe we require doctrinification for unit-tests, but it would probably be ideal that unit-testing avoid pre-doctrinification code (or refactor it), for a cleaner codebase. As I mentioned earlier, I think the biggest ordeal will be doing mockups for various db-required testing.

Yes, some of BM is poorly suited to unit-testing and needs some better form of functional testing. Yes, one *could* begin implementing unit-testing as part of all new code, if not refactoring the whole code. Yes, we have primarily one active dev and adding additional development process will increase time. Yes, doing it now is good policy for down the line.

So to summarize - need more volunteer devs with time and knowledge to do this. And many more things. Using a test-driven development process while fixing the numerous bugs would fix both bugs and see some tests implemented.

Octavius, I don't think it a matter of miskel 'being proved right'. I think we can recognize the benefits without seeing it in practice, but as you mentioned, it comes down to free time by volunteers.

[De-Legro]

I write lots of unit test for work, as well as integration test and validation tests. I do so because I have to the systems I design control packages for often have costs measured in the tens of thousands of dollars when they are down and not producing, so I can't afford for bugs during commissioning. The reality of volunteer projects is that very very few ever implement unit tests and the few that do generally do so in one big push and then never update them. The reason is simple, even though in the long term there are time savings in the short term it is a massively boring undertaking. Volunteer projects need the devs to be motivated, interested to actually keep them around and giving up their free time to produce something. As soon as that effort is no longer entertaining, you lose them to something that is.

Before Unit testing could even be considered in the current code base every part of the code requires proper documentation. I know that I often look at parts of the code and can only guess at why certain restrictions and such are included. Are they intended? What is the goal of the code? Unit testing only works once you actually know what the result should be.

So the end result? To keep the game moving with ANY new features, as well as needed bug fixes unit testing would be relegated to at least the same time frame as the doctrine conversion, IE still happening. It also requires someone to seriously take it as their little project in terms of overseeing it, else the newly written tests will become invalidated as people edit the code or make bug fixes and don't ensure test are updated if required. In a system where dev time is already stretched I just don't see it happening.

If we were to make a move towards unit testing, I would suggest using codeception.

[Jens Namtrah]

If you add unit tests correctly, and use continuous integration with your repositories, then you MUST keep your tests up-to-date or you cannot push your new commits - you will be blocked from doing so (except for new functionality, of course).

You start with a simple framework and write some very, very basic tests. Then as you work, you refactor the simpler parts of your code so they they have tests. You don't sit down and make adding tests a new project that you work on for months. You gradually, one or two chunks of code at a time, add these in. You build them up over time.

Yes, even this priest issue is something that would be covered by Unit Tests. If you don't think so, you simply don't fully understand what they are. Yes, you will need to do considerable refactoring - which is why you take it in small steps.

I think you should focus on existing code, adding a test each time you fix a bug so that you know your fixes are correct, and so you won't ever have to spend time going back and fixing them again while you are trying to write new code features. However, if after learning about them you think you'd rather start with TDD on your new features, there's nothing wrong with that approach. I would caution against it though - you are most likely going to try to reuse existing code, and since that will be untested and have bugs, I think you'll find you will need to do even more test writing than if you just refactored small things.

What does NOT work, however - as some people have suggested - is to try to have one person who writes test for everyone else. That simply doesn't work. If everyone isn't on board, there's no point bothering.

[De-Legro]

If you add unit tests correctly, and use continuous integration with your repositories, then you MUST keep your tests up-to-date or you cannot push your new commits - you will be blocked from doing so (except for new functionality, of course).

You start with a simple framework and write some very, very basic tests. Then as you work, you refactor the simpler parts of your code so they they have tests. You don't sit down and make adding tests a new project that you work on for months. You gradually, one or two chunks of code at a time, add these in. You build them up over time.

Yes, even this priest issue is something that would be covered by Unit Tests. If you don't think so, you simply don't fully understand what they are. Yes, you will need to do considerable refactoring - which is why you take it in small steps.

I think you should focus on existing code, adding a test each time you fix a bug so that you know your fixes are correct, and so you won't ever have to spend time going back and fixing them again while you are trying to write new code features. However, if after learning about them you think you'd rather start with TDD on your new features, there's nothing wrong with that approach. I would caution against it though - you are most likely going to try to reuse existing code, and since that will be untested and have bugs, I think you'll find you will need to do even more test writing than if you just refactored small things.

What does NOT work, however - as some people have suggested - is to try to have one person who writes test for everyone else. That simply doesn't work. If everyone isn't on board, there's no point bothering.

Welcome to the world of volunteer systems. Generally we don't want to have too high a barrier to people wanting to join the team as coders. We have in the past had people joining with very little PHP and coding experience. Requiring them to learn a unit test system at the same time they are trying to learn PHP would I think be daunting.

With regards to continuous integration into our GIT repository, I have to admit I don't even know what servers our GIT is on, if we control them and if they can access the test server for running automated testing. GIT is not something I personally use or have great experience with.

By the way the nature of the Priest bug means unit tests would not have detected anything. Individual software modules were working correctly. In that case a integration test system would have been needed to have any chance of detecting the edge case problem with the interaction of separate systems.

[Jens Namtrah]

By the way the nature of the Priest bug means unit tests would not have detected anything. Individual software modules were working correctly. In that case a integration test system would have been needed to have any chance of detecting the edge case problem with the interaction of separate systems.

Sorry, you're correct on that - have a bad habit of saying "Unit testing" when I mean "testing"

As for the rest - if they are able to learn Doctrine, they are able to learn simple Unit Testing. There comes a time when you need to keep the bar at a certain level, or end up going backwards all the time.

There's a reason the Peace Corp doesn't accept most applicants - well-intentioned as they might be, a volunteer who doesn't know anything does more harm than good.

If they don't know how to code php, they should get involved in other ways. You can say that sounds harsh, but you wouldn't accept volunteers to build bridges in Africa just because they have good hearts, right? They should actually know something about bridge building.

If they REALLY want to be coders, then tell them to learn how to code unit tests first. Will make them more useful to the world in general. Being a coder is not 100% about writing code.

EDIT: for those interested in learning more, here is a decent definition of some different types of tests:
http://programmers.stackexchange.com/questions/214529/how-to-create-unit-integration-tests-for-my-web-app

[Indirik]

... you wouldn't accept volunteers to build bridges in Africa just because they have good hearts, right? They should actually know something about bridge building.

If you put out the call for volunteers, and the only five people that responded knew nothing about building bridges, then you probably would. Otherwise, you'd never build that bridge.

The reality of this particular project is that there are no experienced coders volunteering. It's not like the dev team is turning down coders left and right. There are no experienced coders volunteering. If we limit our system to only accept volunteers that are already experienced coders, and perhaps have testing experience, then we won't have any volunteers.

If the entire dev team consists of one self-taught, volunteer coder who is already overworked trying to implement and maintain the code base, and maybe two self-taught, part-time bug fixers, then there simply is no experience, time, or motivation to make any sweeping changes to the system. Despite the possible advantages that any kind of coherent testing suite could possibly bring to the game, it will not happen for the simple fact that there's no one available to do it, or even capable of doing it.

There is a small, finite amount of time available for the volunteers to maintain and expand the game. This kind of project simply cannot afford the overhead that large corporations and popular, well-staffed open-source project can do. You can point to all the web pages, white papers, and tutorials you want. In our situation, it's just not going to happen.

[Chenier]

And pretty much all of this should be moved to a new thread...

[Jens Namtrah]

Good chance it's a self-fulfilling prophecy, or vicious circle, or whatever.

Experienced programmers don't want to work with a group of people who are going to argue all day long that they don't have time to do things correctly.

"Incorrectly done" is a huge pain in the ass. If I volunteer, I want to sit down and get things done  - not spend 20hrs on a simple task because everything around it is buggered. That precisely why I have no interest in volunteering to help with BM code, and I imagine a lot of the other programmers who read these forums feel more or less the same.

I don't think you realize how quickly experienced programmers can write good code, and how unattractive it is to us to join a project where we can't apply those things.

TL;DR; - fix your attitudes, you'll get better qualified volunteers.

[Indirik]

That precisely why I have no interest in volunteering to help with BM code, and I imagine a lot of the other programmers who read these forums feel more or less the same.

I don't think you realize how quickly experienced programmers can write good code, and how unattractive it is to us to join a project where we can't apply those things.

You just don't listen, do you?

Not a single person here has ever told you that BattleMaster will never implement any kind of testing because: 1) we don't want to, 2)we don't think it will help, or 3) that we don't need it. What we've said is that the *current* team, which consists almost exclusively of a single volunteer, can't do it for various reasons that you have chosen to simply dismiss and/or ignore.

Given the reality of our current situation it cannot happen. Anaris already told you this: "If you want to join the dev team to do that, and have the skills required, then I'd be willing to bring you on at least on a provisional basis. (Only Tom can make the final approval of dev team members.)" If it's as simple and basic to get started as you seem to be implying, then surely it would only take a minimal effort from you, right?

So here's your chance to help solve what you have identified as a critical deficiency of BattleMaster development. You can either choose to help fix it and get the dev team on track with writing better code, or you can continue to write lengthy posts about how everyone not doing it your way is doing it wrong, and not do a single thing to actually help improve things. Either way, I'm doing with this topic.

[Jens Namtrah]

Hallelujah!

Now you can stop cluttering up a thread with comments that show you aren't following the conversation & don't understand, and we might get somewhere!

A SINGLE dev who has NEVER used Unit Testing before and has NOTHING more than a tutorial to work from can be up and running in an hour or two with his first simple tests.

Furthermore, the difficulties he has will teach him precisely why his current code is bad (because most of the code will be untestable without refactoring) so he can start to change his coding style for the better.

Anaris, unfortunately, seems to still harbor this idea that it will takes "YEARS AND YEARS" to get going.

This is exactly what EVERY dev thinks at first, and why so many take so long to adopt it. Ironically, it is precisely people like Anaris and his role in BM that Unit Testing (and other forms of testing) that it has exploded in use in recent years.

- People who don't have time
- People with a mess of spaghetti code, where they can't tell what they are affecting when they make changes

As I explained, you can't just have one person step in and start writing tests - it doesn't work like that. You'll probably need to refactor much of your code to make it testable in the first place. It is a system change, not an enhancement to be snapped on. If one person writes tests, but the other isn't using them, they are all worthless.

The first step is for Anaris to say, "Yes, I think Unit Testing is important, but I need help getting started" and then I'm sure there are plenty of people who will lend a hand. But if he's not on board, there is no point anyone else wasting their time.

[Zakilevo]

Who cares if the code malfunctions? Anaris will fix it in time. It is a free game with voluntary developers. Why do you care so much? They are coding this game out of love for this game.

[Jens Namtrah]

That really doesn't make any sense.

Or if it does, that means they aren't even trying to be programmers, just "game makers",  so forget the whole thing.

But I certainly hope they are trying to do the best they can.

Every hour they spend fixing bugs is an hour they can't spend making some new feature. If you fix the same bug 5 times, that's 5 hours you could have been building something cool, but instead you wasted.

In addition, when you write code in a testable design, it makes all of your code easier to work with and to modify - meaning that the next time you want to add a cool feature, it takes half as long to do.

Furthermore, if you are writing good class-based code, you can get other devs to volunteer just to make small modules for you - they don't need to have access to your db, or you entire codebase, in order to create the back-end logic for a new feature. So, you can get MORE volunteers who are afraid to make a large commitment but would be happy to give you a few hours from time to time.

THIS IS WHY "I don't have time" is such a horrible argument.