?

Log in

No account? Create an account

Previous Entry | Next Entry

Leaning on a jet plane

Mucho, mucho test code writing in the past two days. I'm probably 80% done, and I'm scheduled to finish at the end of next week. And as I'm building test code, I'm testing my code that the test code is designed to test, so by the time I am done, my code will automatically pass.
Until I'm forced to change it.
Of course, the schedule is very (ahem.) dynamic. Just today, I had a task removed that started in September and finished in November. So right now, I don't have anything to do between September and November, then I'm back on into March.
That will get fixed. We already looked at the schedule and found some major flaws (like my next component is due to start coding before the design is done), and the screwy reverse orientation of the task loading (if I have a task that is scheduled for 20 hours and I spend 50% of my time on it, the schedule does an elapsed time of 10 hours).
I've stopped believing in the schedule at all. It's just easier that way.
Currently we have delivery to PV&V in early January. That should hold, but integration is pretty skimpy on the schedule and I just don't believe that the integration will go smoothly. "That's what testing is for."
I do snicker.

We have unit tests, which are basically white-box tests. The component is a task, and the testing treats the task as the box, with only the members visible; we aren't delving into the innards of each method (thank you!). The inputs are exercised through the test program, and the easiest way to do this is with a helper class that provides accessor methods for the protected members of the class under test.
Part of the problem is that there are various pieces which are not finished, so we have to stub them out. And for me in particular, I don't have outputs from my module, so I have to fake some pretty big chunks of the system services.
And then there's this data-object-reader thing: on of the guys on the team is really proud of his object-oriented communication design, so he has forced his particular piece to this rather convoluted bit of arcanity where when a message is received, rather than reading the message and getting the data, I have to instantiate a data reader object, use it to retrieve the data using accessor methods, then extract a pointer from the data for each piece of information and use that pointer to provide a domain ID, which is then passed into a new instance of a units conversion manager class which will then provide yet another message object that holds the data that I wanted in the first place.
And all I want is an offset distance and vehicle speed.

Can't... breathe... head... up... ass...

So I had to create a class that would fake out his whole system and provide the data that I wanted by sending a single message. Took me two hours, but I did it. And it works.
And I know that he is going to end up changing this system yet again, which will force me through another round of test plan, review, test code, review...

I wouldn't mind it so much but that it's just silly and I end up doing a lot of work that will be thrown away, all under the pressure to get things done faster.

You know, I'm quite happy to do redesigns of my own systems where I know that it will only impact me. Or if I have an interface designed, I can feel free to do whatever I want to do as long as the interface stays the same. But when someone changes the interface of the freaking MESSAGING SYSTEM, it causes havoc through the entire system.

Not that I'm bitter or anything. :*

I am so outta here, I'm like gone, man.

Latest Month

April 2012
S M T W T F S
1234567
891011121314
15161718192021
22232425262728
2930     

Tags

Powered by LiveJournal.com
Designed by Tiffany Chow