Author Topic: Unit Testing | Code/Peer Review | Coding rules  (Read 2304 times)

Cyberman

  • No life
  • *
  • Posts: 1575
  • Karma: 8
    • View Profile
Unit Testing | Code/Peer Review | Coding rules
« on: 2006-05-12 05:25:19 »
Ok I would prefer to have small pragrams (apart from the main program) to unit test with.
Should these be collected in a directory called 'test'? or something akin to that?

What I'm getting at is
make test
<much compiling>
ISO test
<various test information displaced>
ISO FS test
<more test information about reading file data and reading file sizes etc>

These can return information that can cause make test to fail (which is a good idea)
Also it allows each unit section to be tested when someone changes something to be sure it works acording to spec.

This is how I discovered a bug in my ISO structure information under Linux I'm not sure if it does the same thing under windows or not.
I'm trying to comply with some sort of 'standard' we need too use throughout the coding process to test things.  It may seem picky but I've attempted to wade through bugs before and it's best to test everything that needs testing in each unit so the bug is swated before a bug becomes an unfindable flaw.

The next thing is Peer Code Review of the code.

This has saved my backside.. and I think we do need it. (See i++/++i and vector class discussion).
When it comes to STL I'm weak. I predate STL (period) so I will have to learn it now I suppose (mutter) ;)
In fact I predate Template usage in C++

That being said.. we should be careful with C++ constructors and destructors as well as inheiritance usage.
Porting to certain platforms will be made impossible if you rely on any static objects and the compilor to create them in some sane sequence.
(Palm OS is one such animal for example).
This again is why Peer review might be valuable.  It's not about trust it's more about making sure the code works without later major revisions on several platforms.  Obviously PC's will be the first platforms to run it, (Linux Windows et al).  Even porting to winCE make require some important changes. It's best not to paint ourselves into the proverbial corner and have to tear out the floor.

Cyb

halkun

  • Global moderator
  • No life
  • *
  • Posts: 2111
  • Karma: 20
  • NicoNico :)
    • View Profile
    • Q-Gears Homepage
Re: Unit Testing | Code/Peer Review | Coding rules
« Reply #1 on: 2006-05-12 06:02:54 »
The problem is that the makefile that crazy_otaku has is auto-generated. I'm editing it as I see fit, but this, in the long run isn't going to be very helpful. We probably need to move to automake or at least imake so that we can have a preprosesser for the makefile. The only thing I'm doing right now is simple cleanup to get the code to compile under linux, but without a grip on c++, I'm getting myself really lost with objects quickly.

Akari

  • Moderator
  • Freak
  • *
  • Posts: 761
  • Karma: 26
    • View Profile
Re: Unit Testing | Code/Peer Review | Coding rules
« Reply #2 on: 2006-05-12 18:44:55 »
Quote
Ok I would prefer to have small pragrams (apart from the main program) to unit test with.
Should these be collected in a directory called 'test'? or something akin to that?

It's good idea, but do we really need each test? I think we need to add debug info in q-gears, so we will not met situation like halkun's segfault ever again.

Quote
This has saved my backside.. and I think we do need it. (See i++/++i and vector class discussion).

This is not a matter of style. It's matter of effectiv usement of C++
please read books of Herb Satter and Scott Mayers (you could easyly found them in the internet). They talk a lot about optimisation and effective C++ programming.

Quote
That being said.. we should be careful with C++ constructors and destructors as well as inheiritance usage.
Porting to certain platforms will be made impossible if you rely on any static objects and the compilor to create them in some sane sequence.
(Palm OS is one such animal for example).
This again is why Peer review might be valuable.  It's not about trust it's more about making sure the code works without later major revisions on several platforms.  Obviously PC's will be the first platforms to run it, (Linux Windows et al).  Even porting to winCE make require some important changes. It's best not to paint ourselves into the proverbial corner and have to tear out the floor.

I want to try port our engine to PSP =)
Gladly they have STL and OpenGL, so we can make it =)