Posts Tagged ‘test’

Posted by Tatyana at 12 January 2012

Category: Dev, Java

Tags: , , , , ,

Well, maybe not in theory, but in practice – definitely.

Test-drive development is a way to program where you write an automated unit test that fails first, then you write code and check that the test runs ok. Brilliant theory for an ideal world (doesn’t exist). In practice however it is very seldom that you as a programmer have a full and clear understanding of what is it you are gonna do.

Of course I’m not talking about cases where you need to calculate the result of 2+2. Sure you can write a test case here.

And here comes a hard reality where you come to the real place, f.ex. a bank that needs a new program. And here you are with a task that states smth like this “Create a form that have these and these fields and calculates that and that”. You begin with a test case? You are right! That’s what happens if you do this: you kill several days  trying to understand how you build this test case, what fields you need to fill inn to calculate the result. If you’ll try to check a more specific result then you need several extra days to find a person who maybe knows how the value must be calculated.

Because it is very seldom in the real world that programmers work together with persons who both know and can explain to the programmer how the things should be done. Simply because those persons do not exist.

So you wrote the test and now you need to write a calculation algorithm… Hmm, how the hell do we do that? We start building it and magic happens! The algorithm that can calculate the value needs all totally different input values then those you’ve written in your test case… Ouch! It happened again?

At the end you’ve used double time to write the code and update the test case in parallel plus the time you’ve killed on the test at the beginning.

So why is it so popular to talk about it and constantly try to use it? Do not know. You need to write test cases when you program difficult logic. That is the fact. But doing it FIRST? It’s just a waste of time and killing of enthusiasm. You won’t be clever and you’ll not write better code if you kill time with the test first.

What really needs to be done before you start programming is to draw a solution.

VN:F [1.9.13_1145]
Rating: 0.0/5 (0 votes cast)
Share

Posted by Tatyana at 25 February 2010

Category:

Tags: , , , ,

The book by Robert C. Martin “Clean Code” is a really very useful material for all programmers. You can disagree with him sometimes (as I do), but it still provides some useful notes that helped me to place my programmer experience and knowledge where they belong. Here I’ll provide some key notes that I did while reading the book and that I’d like to memorize.

What you as a programmer SHOULD DO:

1. Give everything meaningful, searchable and pronounceable names.
2. Use names that other programmers can understand. Remember that the code is for programmers, not customers.
3. Functions should be small and smaller than that.
4. Functions should do one thing. They should do it well. They should do it only.
5. The ideal number of arguments for a function is zero. Max 3.
6. Prefer exceptions to returning error codes. Create informative error messages.
7. Prefer meaningful names to comments.
8. Write JavaDoc only for public API’s.
9. Format your code. While working in a team use a single formatting style.
10. Test your code with clean tests. Remember that test code is just as important as production code.
11. Test just one concept per test.
12. Test should follow the FIRST rule:

    Fast -  tests should be fast.
    Independent - tests should not depend on each other
    Repeatable - tests should be repeatable in any environment
    Self-validating – the test should have a boolean output
    Timely - write unit tests before the production code.

What you as a programmer should AVOID:
1. Avoid encoding
2. Avoid duplicate code. Watch out not only duplicate functions but also duplicate functionality.
3. Avoid noisy, redundant, uninformative comments. Remember that one of the more common motivations for writing comments is bad code.

VN:F [1.9.13_1145]
Rating: 0.0/5 (0 votes cast)
Share

Posted by kent at 1 December 2008

Category: Ikke interessant

Tags: , , , ,

I just bought myself a shiny new GPS yesterday, the choice was hard, but it was Garmin who picked the longest straw. The other competitors was Mio and TomTom.

Garmin nüvi 765T

Garmin nüvi 765T

I’ve had it out for a few testdrives here in Oslo. It had all the roads I were driving and it easily managed to calculate new routes when I turned right when I’ve should have gone straight forward or left.

The display is large and colorful, but the touchscreen is somewhat slow when I try to scroll the map or rotate the map. It’s 3D view of buildings is ok, but it isn’t exactly the latest FarCry2 engine. While driving you want to keep your eyes on the road, not on the 3D buildings, so it doesn’t really matter.

It has lots of Points of Interest (POI), though I’ve only checked some major ones. There are lots of restaurants, bars and gas stations on the map. Big plus for having both IKEAs in Oslo available as a POI! :)

The second time I were out driving wasn’t that cheerful. It’s live traffic alarm wasn’t spot on. In fact, it didn’t get anything right. One place it marked a whole section of the road as road work with a 2 minute delay, but there were none. It also guided me through the busy parts of the city with mostly red traffic lights at every intersection. As a “bonus”, as I might call it, it literally died upon me. Luckily I was familiar in the area so I managed to get home on my own. My wife tried to revive the GPS by holding the off button pressed for a long time. It didn’t respond. It displayed the map from where it froze. When I got home it finally could be revived by pressing the off button for 5 seconds. A big disappointment!

When I’m more familiar with this unit, I’ll post an updated review.

VN:F [1.9.13_1145]
Rating: 0.0/5 (0 votes cast)
Share