Problem: Traffic Flow
Naming

I strongly recommend you read through the official C# naming conventions. Here are a few rules to keep in mind:


Properties are UpperCamelCase
Private fields are lowerCamelCase, sometimes prepended with an underscore
Methods are UpperCamelCase
Local variables are lowerCamelCase
Test methods should be descriptive [more information]


Applied to your code, here are a few changes to make:


TestMethod1 -> TimeToWait_WithFiveMinutes_ShouldReturnZero
mycar -> currentCar
lengthbetweenLights -> lengthBetweenLights 
getTravelTime -> GetTravelTime


Also keep in mind that your naming should make sense in light of the contest: MyCar does not really make sense in the sense of a Traffic analysis: what if I want to calculate it with someone else's car? Therefore I suggest making it CurrentCar instead.

This is part of the encapsulation I talk about next, but keep in mind that hiding the implementation details by not putting them in the variable's name, is also a form of encapsulation. 

Right now you have a variable named LightList which tells me that it concerns a list of lights. Except, I already know it's a list because I can see the type. But what if you want to go more general and make it a ICollection instead? Or you want to group them with the amount of dogs that peed against it: Dictionary&lt;Light, int&gt;. Now your name doesn't fit anymore and you'll have to change it (and make version control ugly).

Methods are actions: you perform an action on the instance. What kind of action is TimeToWait? I would have expected it to be a property from the way it's worded. GetTimeToWait makes it clear that I will receive a value (and just that).

Encapsulation

Definitely read more on the topic of encapsulation, a cornerstone of OO-Programming. Your Traffic class has public fields which are open for modification. By forcing to do this through setters (an auto-generated property is a setter!) you can satisfy encapsulation and force whoever wants to modify it to go through your setter first. This means that you can add validation logic before touching the backing variable.

Instead what you should do is work with a public property like 

public Car CurrentCar { get; set; };


[More information on fields and properties]

Events

Traffic lights that get their status updated every second sounds like a good option to put events in here. You could keep counters elapsedTime and switchTime and a flag isGreen so your light can articulate its state to callers. This would make your methods IsGreen() and GetTimeToWait() more intuitive: you don't have to call them with an argument to signify the current time.

Although this might be overdoing the assignment a little bit.