Language:
switch to room list switch to menu My folders
Go to page: First ... 32 33 34 35 [36] 37 38 39 40 ... Last
[#] Fri Aug 28 2009 15:11:14 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


... and draw up a list of requirements, none of which make sense.

[#] Fri Aug 28 2009 22:04:02 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I remember once when they called what I was doing "stakeholdering."
I shit thee not.

[#] Wed Sep 09 2009 14:02:41 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

He's right, of course ... the StrBuf class, the template engine, the

new readloop ... all of these improvements are conceptually nice, but

the implementations all needed a lot more testing than they received.


Sounds like stuff that could have been covered with automated unit tests with relative ease. Note: automated unit testing virtually *dictates* that you write your software in an OO fashion, with (in C++ parlance) lots of virtual functions everywhere.
'

[#] Wed Sep 09 2009 14:37:20 EDT from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

 

Wed Sep 09 2009 20:02:41 CEST from LoanShark @ Uncensored
He's right, of course ... the StrBuf class, the template engine, the
new readloop ... all of these improvements are conceptually nice, but
the implementations all needed a lot more testing than they received.


Sounds like stuff that could have been covered with automated unit tests with relative ease. Note: automated unit testing virtually *dictates* that you write your software in an OO fashion, with (in C++ parlance) lots of virtual functions everywhere.
'

unit tests: yes. thats why I started them (a little late, last weekend) with http://cunit.sourceforge.net Its far from complete and I probably could use some help there. If you want to volunteer...

Object oriented fassion: yes. it is.

Virtual Functions: no need for that.

C++: no need for that.



[#] Wed Sep 09 2009 16:15:42 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Virtual Functions: no need for that.

No, sorry, but once you start writing unit tests in the large scale, you will understand. Code needs to be written to maximize unit-testability. When you write code that's designed to be testable, you will do things that you wouldn't have done if you were just designing for performance.

When you design for performance, you are basically writing assembler code except it's in a high-level language.

But when you write testable code, you are writing exquisitely modular code that makes very few assumptions about what it's interfacing with. Basically you need to code to interfaces or abstract classes all over the place, so that you can test one unit (typically, unit=a class) at a time without becomingb bogged down by coping with that unit's interactions with other units.

So you replace the other units with mock implementations tthat do something artificial, for test purposes. I know a lot of people who are new to unit testing say "no, but that's artificial, that's not testing a real scenario, that's not testing your whole application from end to end."

This is totally missing the point of unit testing. Unit testing isn't SUPPOSED to test everything from end to end, it's simply supposed to be a step in the right direction of having a test for ANYTHING, at ALL. Also, unit testing gives you a way to achieve 100% test coverage without the extreme complexity of devising functional test cases that would achieve the equivalent coverage. Functional testing for the same coverage is always more difficult because of the number of paths through the code that must be traced. It's more difficult in terms of developer man-hours and it's also more difficult in terms of the CPU and disk resource consumption of the automated tests, because the entire application must be executed repeatedly, with many different inputs, to achieve the same coverage. For a reasonably complex application that accesses a database, for instance, this will result in many many calls to the database layer, more than is needed to actually test the database layer. So really, making a mock implementation of AT LEAST your database layer is the only sane way to proceed.

This naturally maps to object orientation, and you end up coding to an interface that you can swap out. That means virtual functions, in C++ parlance. Of course you can do virtual functions in C, by passing around pointers to jump tables. But it's really pointless to bother doing so. If you are already doing this design pattern, you have already lost the (slight) performance advantage of remaining in C-land. It's actually better to move to a language that can manage that for you--and in the right circumstances, you can regain the lost performance by using a compiler and runtime that are aware of object orientation and can optimize it for you. If you're using OO concepts, it's really better to use a language that can express those concepts as a first-class language construct and does not relegate them to the status of a second class citizen.

[#] Wed Sep 09 2009 17:19:50 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I like the idea of unit tests, but I don't understand how they can be applied to code which implements a user interface -- which happens to be where the bulk of our bugs are right now. How is that normally achieved?

[#] Wed Sep 09 2009 17:51:28 EDT from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

While not having done TDD before, I'm not new to that concept.

The first thing I'm going do unit tests for is StrBuf (where i've already started); its a set of discrete functions all doing one specific transformation on a stringbuffer; The most complex one is the RFC822/iconv decoding one. I generaly expect this to be doable, but work.

The next thing on the list is our list implementation, which is going to be a little more difficult, but doable too, maybe a little more tricky.

once it comes to webcit, its going to be more complicated; everything I did was done in a way to concentrate server I/O in one place per command which does de-serializing of the server data into the local structures. So here mock objects will be entering the game. The templating stuff is going to be more complicated; I think blackbox testing from the outside is more apropriate here.

Several other criteria were applied; we always know the lengths of our string snippets, and can paste them together pretty quick.  The other big one is to resolve what we're able to resolve at start time, so it doesn't affect our runtime performance. Yes, these afunction pointers are used all over the place; they give us a good modularity and resolve many of the interdependencies which were there before. Static constructors are done via a shellscript which gives us the hook api functions; dave introduced this design pattern.

Close interaction with the profiler  and the above design criteria give us a pretty fast thing, which i'm verry confident that its faster an it was before; we've got reports that we're pretty fast on 486's and became much faster with all the above changes. So, no, we're not leaving it to the compiler or some bytecode intepreter to do some vodoo magic beyound our control, we do it ourself.



[#] Wed Sep 09 2009 18:14:29 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

faster with all the above changes. So, no, we're not leaving it to the

compiler or some bytecode intepreter to do some vodoo magic beyound our

control, we do it ourself.

This is a nonsense statement. You just stated that you're using function pointers all over the place. That's not "doing it ourself", that's "not doing it at all", in terms of optimization. As for static constructors.. it's really unfortunate that the C++ ABI is still not portable enough to do static ctors/dtors as nicely as developers want it.. but the support is there. The only real problems I'm aware of are on Mac OS X and just apply to shared libraries... which shouldn't be a problem for you guys. (But it's been a while since I've looked at this area of C++ as I mainly develop in superior languages. ;)

[#] Wed Sep 09 2009 18:26:24 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Sep 9 2009 5:19pm from IGnatius T Foobar @uncnsrd
I like the idea of unit tests, but I don't understand how they can be

applied to code which implements a user interface -- which happens to

be where the bulk of our bugs are right now. How is that normally
achieved?



I'm not going to lie and say it it's easy, because it's not without its difficulties. In fact, we typically leave it to our QA department to do the bulk of the browser testing...

But the typical approach on the server side is the MVC design pattern, which allows you to separate your code into Model, View (user interface), and Control (logic.) The idea is... Control and Model are the easiest parts to test, and you try to move as much of your logic into those 2 layers as possible, and out of View. I.e., every time you write an "if" statement, in theory you have to write at least 2 automated test cases, one of the taken case and one for the branch-not-taken case. So you try to keep as many of those "if" statements nicely decoupled from the View layer, as you can.

At my previous employer, we went really apeshit and designed, in Java, a Qt-esque object framework that was designed to generate HTML and encapsulate all of the commonalities of our HTML generation. While I was still there, we never got to the point where we had significant test coverage for this layer, but I assume that the unit testing problem would be at least somewhat easier to solve with this kind of approach... or at least, it couldn't be any harder, because most developers just give up and don't test their HTML layer at all ;)

Anyway, the only industry standard approach I'm aware of are tools like those available from Rational, which just add a scriptable testing engine to Internet Explorer etc. This approach is both non trivial, and nontrivially expensive, but it's something.

[#] Wed Sep 09 2009 18:40:55 EDT from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Mi Sep 09 2009 18:14:29 EDT von LoanShark @ Uncensored
faster with all the above changes. So, no, we're not leaving it to the
compiler or some bytecode intepreter to do some vodoo magic beyound ourcontrol, we do it ourself.

This is a nonsense statement. You just stated that you're using function pointers all over the place. That's not "doing it ourself", that's "not doing it at all", in terms of optimization. As for static constructors.. it's really unfortunate that the C++ ABI is still not portable enough to do static ctors/dtors as nicely as developers want it.. but the support is there. The only real problems I'm aware of are on Mac OS X and just apply to shared libraries... which shouldn't be a problem for you guys. (But it's been a while since I've looked at this area of C++ as I mainly develop in superior languages. ;)

I don't think there's a good reason to call c inferior. One won't reach the code density of Ruby or Python, or the ability to generate most of your code like in java, but in most cases theres a descent chance to get a faster result using C then with any of the above; while it might take you a little longer.



[#] Wed Sep 09 2009 18:45:31 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I don't think there's a good reason to call c inferior. One won't reach
the

Didn't call C inferior, I called C++ inferior. (To other OO languages.)

[#] Wed Sep 09 2009 18:46:54 EDT from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

 

Mi Sep 09 2009 18:26:24 EDT von LoanShark @ Uncensored
Sep 9 2009 5:19pm from IGnatius T Foobar @uncnsrd
I like the idea of unit tests, but I don't understand how they can be
applied to code which implements a user interface -- which happens to
be where the bulk of our bugs are right now. How is that normally
achieved?
I'm not going to lie and say it it's easy, because it's not without its difficulties. In fact, we typically leave it to our QA department to do the bulk of the browser testing...
...

Anyway, the only industry standard approach I'm aware of are tools like those available from Rational, which just add a scriptable testing engine to Internet Explorer etc. This approach is both non trivial, and nontrivially expensive, but it's something.

We've got selenium to do that with firefox. Openqa.org has a pretty good linklist of other tools; This would be blackbox testing, right?



[#] Wed Sep 09 2009 18:48:39 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

We've got selenium to do that with firefox. Openqa.org has a pretty good

linklist of other tools; This would be blackbox testing, right?

What you are talking about is not unit testing, it's automated functional testing, and I don't really have a lot of experience or interest in it... just tackling the unit testing problem, now.


Automated-functional, I am happy to leave to the QA department, since it doesn't directly impact the way I write my code ;)

[#] Wed Sep 09 2009 19:36:13 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

 

Wed Sep 09 2009 18:45:31 EDT from LoanShark @ Uncensored
I don't think there's a good reason to call c inferior. One won't reach
the

Didn't call C inferior, I called C++ inferior. (To other OO languages.)

Heh... that's because C++ is more of a Generic Programming language than an OO language.  At least, in how it has been designed for a long time now.  The OO features suck, if you're looking for OO.  But then, OO is overrated, I think.

Eh, but we're CitaDrifting into the Programming room.



[#] Wed Sep 09 2009 19:43:23 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


i'm not sure that the OO sucks. My main beef with C++ is its complexity and the fact that the ISO keeps making incompatible changes to the syntax (let alone the libraries.) But complexity is not the same as plain old suckage, if one is willing to learn. There are a lot of things to like about C++, and the strong typing is one of those things. Strongly typed languages basically make more metadata available to both the compliler AND the programmer and her IDE environment and any other toolsets that deal with the code. It's not just people that read and manipulate code; sometimes computers manipulate source code as well. And if you are doing everthing with function pointers in C, then Ctrl+LeftClick will never work in your IDE... there is something to be said for standards and not making use of idioms instead of first class language constructs.

[#] Thu Sep 10 2009 02:41:03 EDT from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

while we did lots of function pointers, theres just one place where I would compare them to virtual functions: the readloop. In all the other places I don't see how to do it with virtual functions or better with C++ language features.

The bugs we had with the readloop rework wouldn't have been there in C++ since you wouldn't be able to use the function of the object elsewhere, as we did in the summary and the smtpqueue.

All other function pointers are due to resolving a string from a table to an action to take.



[#] Thu Sep 10 2009 10:24:05 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Sep 10 2009 2:41am from dothebart @uncnsrd
while we did lots of function pointers, theres just one place where I would

compare them to virtual functions: the readloop. In all the other places
I

Ok, then you haven't started doing unit testing on a large scale yet, and you haven't gotten to the point where you are building mock implementations of core features (like the DB layer)

[#] Thu Sep 10 2009 10:46:23 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

For starters I'd be happy to see a full set of regression tests on the library functions, which are of course very testable, and on any server functions which involve a program talking to another program. UI stuff is more difficult but unit testing is just one aspect of simply taking a more disciplined approach to software development.


[#] Thu Sep 10 2009 14:46:52 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

When you design for performance, you are basically writing assembler

code except it's in a high-level language.

But when you write testable code, you are writing exquisitely modular

code that makes very few assumptions about what it's interfacing with.


YES YES YES!

Now if people would only stop doing that. :-)

[#] Thu Sep 10 2009 14:47:19 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

orientation and can optimize it for you. If you're using OO concepts,

it's really better to use a language that can express those concepts as

a first-class language construct and does not relegate them to the

... Like Objective C. <snicker> :-)

Go to page: First ... 32 33 34 35 [36] 37 38 39 40 ... Last